Python vs Ruby

[D-Man]

On Tue, Jan 30, 2001 at 01:16:31AM -0500, Tim Peters wrote:

[snip rather good and insightfull explanation of python's dynamic
memory usage]

| > ...
| > All the tests I've seen of the Boehm collector used C programs
| > originally designed for malloc/free, not using any ref counting schemes.
| > Maybe this has an effect?
| 
| No C program I know of does dynamic allocation on virtually every line.
| Python programs do.  C++ is somewhere between them, but closer to the C end.

Good point.  Also describes why python is not good for kernel or
device driver programming.

| 
| > I wonder if python was designed for the collector instead of ref
| > counting if this would improve its performance . . .
| 
| There's no sense in which Python was designed "for" ref counting.  The

By "designed for ref counting" I meant that the way functions "own"
memory and take responsibility for the memory is different than if
traditional C techniques were used.  (that is, defining in
documentation that some function owns the memory and has the
responsibility of free()ing it)

I am noticing now how we said "Python ...".  I think we both mean
"The Python interpreter ..." not the Python language. :-)

| single highest-payoff thing it could do here, regardless of garbage
| collection scheme, would be to grow a lot of hair to *exempt* some objects
| from participating in the gc scheme du jour.  For example, in a language
| with more sanely static semantics, it would be easy to see in the example
| above that there's no need to allocate an integer object for the result of
| id(s) each time through the loop -- it could just store that result on a
| stack (or in a register) and exempt it entirely from refcounting (or M&S, or
| whatever).  Similarly for the loop index "i", and the function object
| "choice".
| 
| BTW, note that Perl also does refcounting, and for the same reasons.  The
| idea that fancier gc schemes must be faster is ... an idea <0.9 wink>.
| 
| if-anything-about-gc-seems-obvious-it's-an-illusion-ly y'rs  - tim
| 

Does the interpreter always call free() when the ref count is 0?
Sometimes (in the short run anyways) gc can produce faster results
with some operations -- you can keep working and wait to do the actual
free()ing when the application is idle.  

If the interpreter used gc, it would certainly be simpler to write it
and extension modules -- no worrying about whether or not to INCREF()
or DECREF().  But there are other tradeoffs as well, speed and
intermediate memory usage being two that you have described in favor
of refcounting.

>From the python code side of things, it really doesn't matter (much)
whether ref counting or gc is used.

On the other hand, take Java.  Early JVMs ran the garbage collector in 
such a low priority thread that deallocation of memory almost never
happened. 

I'm-not-saying-that-python-should-drop-refcounting-and-use-gc-ly y'rs -D