Python and Boehm-Demers GC, I have code.

[Markus Kohler]

"Tim Peters" <tim_one at email.msn.com> writes:

> [Tim]
> >     for i in xrange(10000000):
> >         pass
> > [and RC vs GC implications]
> 
> [Markus Kohler]
> > True.
> > IMHO this is one of Pythons major design flaws.
> 
> What, specifically?

That flaw is that loops are not implemented using closures. 
Instead as far as I understand   loops in Python are implemented such that
the loop counter is created and destroyed for each step of the loop. 
Even if you optimize this heavily you will probably slower than with a design
that "recycles" the loop variable. 

You could compare this to tail recursive versus non-tail recursive functions. 

Also closures make the implementation of efficient loops more difficult they
have the advantage that loops and other control structures can be better integrated
into the OO concept. Smalltalk for example doesn't need Iterators for that reason. 

> 
> > 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.
> 
> Sorry, I've missed what "the problem" is thought to be here.  Loop overhead
> is typically lareger in Python programs than in other languages, but is also
> typically trivial all the same.
> 
> > Loops in squeak (www.squeak.org) are already 2 to 3 times faster
> > than in Python.
> 
> All possible loops?  All loops you've personally timed?  One loop you timed
> in a moment of boredom <wink>?  An empty loop that counts to 10000000?  I
> don't doubt that Squeak is faster in many areas and for many reasons, but
> I've been running Python for most of the decade and reducing loop overhead
> is about the last thing I'd bother to aim at.

Lately ee have had already some examples in this group  where loop overhead was 
a major factor. 
I measured different kind of loops and even the more general while loop was faster
in squeak than anything else in python. 
Functions calls seems also to be much slower in Python ...


> 
> > ...
> > Is there anything that would prevent someone to reimplement loops
> > such that only one variable is allocated ?
> 
> In the loop above, there are actually two int objects created per iteration:
> the one explicitly created by xrange and bound to "i", and a hidden "loop
> counter" int object used to drive the for/__getitem__ protocol.  The latter
> can be (& has been, experimentally) reimplemented via an internal "mutable
> int" type created for that purpose, but it didn't buy enough to be worth
> adopting.  Most loop bodies contain more than "pass" <wink>, and the more
> work they do the less the fixed overhead matters.

Another problem with loops could be reference counting. 
I'm wondering how often a reference count get's changed when running a loop ... 

Markus
-- 
Markus Kohler  mailto:markus_kohler at hp.com