"Edward K. Ream" <edreamleo@charter.net> writes:
The pypy tools promise to move programming (not just python programming) in new directions. They may show a way to realize an ancient dream of mine, viz., to eliminate the gc for some (most?, all?) objects. For details, see:
http://webpages.charter.net/edreamleo/whitepapers.html#allocating-storage-us...
Um, I think this technique is used reasonably often in the implementation of compilers, is it not? Even Python 2.5 uses it... In the context of PyPy it's easy to think of a program where the use of this technique is less clear: an interpreter.
Of course, nothing at all may come of this; it's just something to keep in the back of my mind. Your (gentle) comments are welcome.
It is certainly the case that memory management is of utmost important to the performance of pypy (looking at kcachegrind for, oo, half a second will tell you that) but it is less clear how to do anything about that. PyPy already performs an analysis or two designed to remove allocations, and a few more have been written but are not used because they didn't help or are buggy. They are all local to a function so far though, I think. Googling around I found this paper: http://www.cs.cmu.edu/afs/cs/academic/class/15745-s06/web/handouts/lattner-p... -- would someone like to read it for me and tell me if it applies to PyPy? :-) The logical extension of the pool allocation idea is a generational garbage collector, and I'd dearly like to have one of those for PyPy but practically speaking you need a copying collector for one to be worth it and we don't support that yet for grotty reasons. Cheers, mwh -- Ability to type on a computer terminal is no guarantee of sanity, intelligence, or common sense. -- Gene Spafford's Axiom #2 of Usenet