"Lawrence D'Oliveiro" <l...@geek-central.gen.new_zealand> wrote in message
news:hm4icr$q4...@lust.ihug.co.nz...
In message <op.u8nfpex8y5e...@laptopwanja>, Wanja Gayk wrote:
Reference counting is about the worst technique for garbage collection.
It avoids the need for garbage collection. It means I can write things
like
contents = open(filename, "r").read()
and know the file object will be immediately closed after its contents are
returned.
It also means I don’t have to predefine how much memory my program will
use.
A garbage collector will only kick in when the app runs low on memory. On
a
system with dynamic memory allocation, that will not happen until the
entire
system runs low on memory, unless you limit the app to some fixed amount.
Which is an antiquated way of doing things.
And then there’s caching. Modern CPUs owe most of their speed to
assumptions
that programs will obey locality of reference. Pointer-chasing is a cache-
hostile activity. Garbage collection involves a lot of pointer-chasing,
particularly of dead objects that have long since been flushed from the
cache, compared with reference counting of recently-accessed objects.
Therefore garbage collection loses performance.
Reference counting is a technique that is only applicable for a subset of
scenarios GC can handle. RC fails when circular dependencies exist. In an
ancient past I have worked with RC-based C++ frameworks and they where
either very restrictive to prevent circular dependencies or ignored them
resulting in memory leaks.
In addition, for fast create/destroy scenario's (for examples loops that
allocate objects with single cycle lifetimes) a generational GC is MUCH
faster than manual malloc/free new/delete code because it enables a
completely different heap management logic. Reference counting only adds to
the slowness in this scenario.
You are also incorrect in stating that a GC will only kick in when memory
becomes scarce. Partial GCs will happen very frequently (thereby
invalidating your point about caching) and are extremely fast. Only full GCs
are infrequent and take more time but they will typically run in a separate
thread.
No general statement about the relative speed of generational GC systems
versus manual heap management (or the slower variant RC) can be made since
they have completely different best, general and worse case behavior and
scenarios.
In response to your original post: please provide links to examples of
quality benchmark results. There are numerous language speed comparison
benchmarks that usually put Python in the tail region with Ruby and the
likes for many different applications. If you have opposing examples then
you should provide them.
Silvio
--
http://mail.python.org/mailman/listinfo/python-list
