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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4