[EMAIL PROTECTED] wrote: > > Paul Rubin wrote: >> The problem here is with a high allocation rate, you have to GC a lot >> more often, which typically involves copying live data. > > This is last century's issue. Copying data, RAM to RAM, is nearly free > using the Intel architecture. > > This short article, http://www.martinrinehart.com/articles/repz.html > explains why. > > I'd use one int per clock as a rule of thumb for the current copy rate > in a single-core CPU.
You have a strange idea of "nearly free", and I find your analysis a little simplistic. You may take advantage of direct memory access, but cycles are still consumed. I presume also (though here my knowledge of present-day Intel and AMD architectures gets a little sketchy) that many data cache lines could still be invalidated by these moves, and that also has a significant effect on performance. Extending an integer array from 100 to 150 items is a pretty puny operation when you compare it with the amount of data that might need to be moved during a compactifying garbage collection of a 20MB Python program image. Not only that, but all pointers to an object have to be updated when it is relocated. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
