[fpc-devel] Modernising Pascal
Sebastian Kaliszewski
sk at z.pl
Fri Feb 25 01:36:58 CET 2005
On Thursday 24 February 2005 14:57, Jamie McCracken wrote:
> > 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.
You could do partial GC as well. No one forces yo to do 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.
Not true. There are GC's with static as well as unstatic pointers
(compacting GC's move pointers, but there are not compating GC's as well).
For example Bohm GC (for C) does not move pointers. And it's GC.
> so
> referencing an object means looking up the actual address in a lookup
> list
Nonsense. It's clear you don't know how typical GC works.
> (so more overhead whenever you call a method or pass an object
> reference).
Nope.
> GC does not use the stack efficiently
Complete nonsense. GC has nothing to statck. Zero, null, nada...
> and has to use a lot
> of heap so its extremely inefficient.
More of the same... It's simply not true.
Besides compacting GC supported directly by the langauge allows for
extremely effective use of heap -- as effective as that of stack.
> Ever see GC compact swap?
Better go learn more:
http://www.iecc.com/gclist/GC-faq.html
> yes but with GC everything would have to be managed
Nope. See above.
> 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.
Whatever. GC has different problems but you didn't touch any.
PS. there exists real-time capable GC (i.e. good for (soft)real time
applications, such thing can't be said about even most non GC memory
allocation systems).
rgds
--
Sebastian Kaliszewski
More information about the fpc-devel
mailing list