Python Memory Manager

[Steve Holden]

MartinRinehart at gmail.com 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/