[fpc-devel] Modernising Pascal
jamie-junk at blueyonder.co.uk
Thu Feb 24 14:57:42 CET 2005
Jonas Maebe wrote:
> On 24 feb 2005, at 13:51, Jamie McCracken wrote:
>>> IMO the best solution for (almost) all of your problems were garbage
>>> collection. GC is part of Oberon, and it would fit into .NET/DotGNU as
>> GC is very inefficient with memory and current implementations tend to
>> cost a lot performance wise too.
> It's *much* faster than reference counting everything. Reference
> counting is more or less the slowest garbage collection technique there
> is (except if only very few objects have to garbage collected). It also
> can't deal with circular references.
Thats why I would want ref count for Tobjects and not Tcomponents.
Partial ref counting should be faster than doing GC on everything.
>> GC gets a lot slower with the more objects you create.
> Reference counting too.
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?
>> 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.
> You get the same problem if you pass a reference counted structure to C
> (or any other language).
yes but with GC everything would have to be managed whilst just ref
counting Tobject would not cause these problems (you cant access a
tobject from C anyhow). Tobject is the only weak point in Delphi's
memory management so I would say using GC to correct that would be overkill.
> fpc-devel maillist - fpc-devel at lists.freepascal.org
More information about the fpc-devel