Home Original page

Python and Boehm-Demers GC, I have code.

Markus Kohler markusk at bidra241.bbn.hp.com
Tue Jul 20 05:58:12 EDT 1999 
"Tim Peters" <tim_one at email.msn.com> writes:

[deletia]
> 
> My guess is that simple refcounting has excellent cache behavior in Python,
> and GC doesn't.  Unlike as in almost any other language, the little loop
> 
>     for i in xrange(10000000):
>         pass
> 
> creates a huge amount of heap trash at a furious pace (even ints "are boxed"
> in Python).  RC can reuse the same little bit of storage over & over (the
> trash is recycled as soon as it's created), while delayed GC chews up some
> large amount of address space over & over instead.  You can test this by
> timing that loop alone (with and without refcounting).

True. 
IMHO this is one of Pythons major design flaws. There is no need to create a new
object for each step of the loop. 
Smalltalk has loops at least as flexible as Python and it doesn't have this problem. 
Loops in squeak (www.squeak.org) are already 2 to 3 times faster than in Python. 

> 
> Note too that Python does no stack allocation of locals or frames or
> anything else:  everything is heap-based, with the most speed-critical
> allocations augmented by assorted internal fast free lists.  Disable the
> refcounting, and the finalizers on the "intense" objects don't get called,
> and then the fast free lists don't get used either.  So the allocation speed
> optimizations Python implements get castrated too.
> 
> I've always said it would take a very sophisticated mark-&-sweep to beat
> RC's performance for *Python* (it's not Lisp, or Smalltalk, or C++, or ...
> under the covers); 

Is there anything that would prevent someone to reimplement loops such that only one
 variable is allocated ?


> if true (& I haven't seen anything yet that changes my
> mind <wink>), you're at the first step of very long road if you want to make
> BDW the primary approach; but it would be great if BDW could be invoked
> "just sometimes" to reclaim the cycles RC can't catch.
> 
> semi-encouraging-ly y'rs  - tim
> 
> 
> 
> 


Markus
-- 
Markus Kohler  mailto:markus_kohler at hp.com
More information about the Python-list mailing list