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 well.
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.
jamie.
Jonas
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
