[fpc-devel] Modernising Pascal

[DrDiettrich]

Jamie McCracken wrote:

> GC is very inefficient with memory and current implementations tend to
> cost a lot performance wise too.

I don't see how GC is inefficient with memory?
Reference counting and (mark/sweep) garbage collection have a different
runtime behaviour: Reference counting occurs with many references to
objects, whereas GC only runs when required, or when idle time is left.


> GC gets a lot slower with the more objects you create.

It's not the creation that costs GC time, instead it's the destruction
of the objects.

> Mixing unmanaged with managed code cause severe performance issues
> (marshalling penalties calling ummanaged c functions)
> 
> Interoperability with C gets increasingly difficult. Writing bindings
> becomes much more complicated and time consuming.

IMO it's never a good idea to mix managed and unmanaged code, to suffer
from the worst from two worlds at the same time :-(

>>GC is worse here because the pointers are not static in GC so 
referencing an object means looking up the actual address in a lookup 
list (so more overhead whenever you call a method or pass an object 
reference). GC does not use the stack efficiently and has to use a lot 
of heap so its extremely inefficient. Ever see GC compact swap?<<

I don't know what GC implementation you're referring to. When memory
gets too much fragmented, every memory manager has to do a compaction,
that's inevitable. But GC offers a chance to update the references to
moved objects, so that no address tables are required. Other memory
managers don't know about the locations of pointers to the objects, so
that moving objects is not possible at all! Consequently GC allows for
better use of available memory, where other methods have to stop with
"out of memory".

IMO you should learn a bit more about memory management, your
argumentation doesn't look well founded to me.

Any comparison of very distinct methods, as for reference counting vs.
GC, requires distinct implementations of the same task. Simply compiling
the same code for different environments or libraries will favor the
model for which that code was written, and never will give comparable
performance figures.

Similarly I doubt that using different models in a single application
will ever show up where which model should be used for best performance.
Even if the performance may increase by tweaking the code in various
places, such a procedure IMO will primarily only reduce the overhead,
resulting from collisions between the different models, in this specific
application. General decisions, like the kind of management for TObject
and TComponent types, may result in different performance gain or loss
for different applications, or for different usage (memory
requirements...) of the same application.


That's why I suggest to keep models separate, so that a programmer can
decide for which model he writes his code. This separation also will
give no room to flame wars about "the" best model ;-)

DoDi