On Mon, 3 Jun 2002, Tim Peters wrote:
[Kevin Jacobs, on Neil's tuple-untracking patch]
Sorry, I wasn't very clear here. The patch _does_ fix the performance problem by untracking cycle-less tuples when we use the naive version of our code (i.e., the one that does not play with the garbage collector). However, the performance of the patched GC when compared to our GC-tuned code is very similar.
Then Neil's patch is doing all that we could wish of it in this case (you seem to have counted it as a strike against the patch that it didn't do better than you can by turning off gc by hand, but that's unrealistic if so), and then some:
I didn't count it as a strike against the patch -- I had just hoped that untracking tuples would result in faster execution than turning GC off and letting my heap swell obscenely. One extreme case could happend if I turn off GC, run my code, and let it fill all of my real memory with tuples, and start swapping to disk. Clearly, keeping GC enabled with the tuple untracking patch would result in huge performance gains. This is not the situation I was dealing with, though I was hoping for a relatively smaller improvement from having a more compact and (hopefully) less fragmented heap. -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com