Reference Counts

[Heiko Wundram]

Am Donnerstag 18 Mai 2006 09:33 schrieb raghu:
> However, the 'non-leaky' one showed a funny trend ...it kept increasing
> the totalrefcount for five iterations (see 1 thru 5) and then dropped
> down by 5 ( See Before 5 : 16584
> After 5 : 16580 ) suddenly and again increase as shown below. However,
> at the time when the script finsished execution, we were not too far
> from the starting totalrefcount (16584 from 16579),

The cyclic garbage collector isn't run after every byte-code instruction, but 
only after several have executed (because of performance issues). That's why 
you see an increase in reference counts, until the interpreter calls the 
garbage collector, which frees the object cycles, and so forth. I don't 
exactly know what the "magic constant" (i.E. number of byte-code instructions 
between subsequent runs of the garbage collector) is, but I presume it's 
somewhere in the order of 100 bytecode instructions.

Why you need the cyclic gc to clean up the data structures my sample creates 
is beyond be, but I'd guess it has something to do with the internal 
structure of dicts.

Anyway, you can easily test this hypothesis by calling

gc.collect()

explicitly in the main loop after test() has run (remember to import 
gc... ;-)). This forces a run of the cyclic gc. If funny pattern still 
remains I wouldn't know of any other explanation... ;-) But, as long as 
references aren't being leaked (you don't see the drop in references after 
every x instructions), there's nothing to worry about.

--- Heiko.