Real Problems with Python

[Tim Peters]

[Tim]
> ...
> (RC has excellent locality of reference, especially when trash
> is being created and recycled at high dynamic rates).

[Vladimir Marangozov]
> That last one is a good one. So far, nobody has shown any evidence
> that LOR is good or bad when different objects are involved (except,
> I remember, some special cases like iterating over ints that happen
> to be allocated close to each other). Better yet, nobody _can_ show
> such evidence as far as one stays on top of a virtual memory manager.

Vlad, you're trying to get "deep" on what is really a "shallow" point:  a
"high dynamic rate" is most likely to occur when a program is doing flat-out
computation, so type homogeneity is likely.  Like ints or floats or whatever
in Python.  And those are *not* "on top of a virtual memory manager" in
Python, but involve cycling & recycling via Python's type-specific internal
"free lists" (some of which you added, so you should remember this <wink>).
So long as the free lists act like LIFOs, you get to reuse the same little
chunks of memory over and over and over ... again.  It's LOR in *both* time
and space, and of course that's "good":  it's the difference between page
faults and, umm, not page faults <wink>.

> make-that-simply-"RC-is-faster-than-the-alternatives"-<wink>-
> -and-I'll-take-it-ly y'rs

I believe there's sufficient evidence that state-of-the-art "real gc" can be
made faster than rc.  Python isn't other languages, though, and so long as
everything in Python is always "boxed", other languages' gc experiences
aren't especially relevant.

not-one-byte-in-python-is-stack-allocated-ly y'rs  - tim