Re^3: Understanding garbage collection specifics...

As an optimisation, perl often doesn't completely clear lexical arrays on scope exit. It frees the elements of the array, but the block of memory it has to hold pointers to the 1E6 elements isn't freed. This is on the assumption that if you entered the block once and created a big array, you're likely to do so again. On the other hand, undef frees the pointer block too.

Dave.

Comment on Re^3: Understanding garbage collection specifics...

Replies are listed 'Best First'.
Re^4: Understanding garbage collection specifics... by cLive ;-) (Prior) on Feb 01, 2007 at 15:14 UTC
So, basically, best practice would be to leave the undefs in the "startup subs" that load and parse XML configuration when the daemon is starting up, but remove them from the trigger subs that get called regularly throughout its life?	[reply]
Re^5: Understanding garbage collection specifics... by dave_the_m (Monsignor) on Feb 01, 2007 at 15:47 UTC
So, basically, best practice would be to leave the undefs in the "startup subs" that load and parse XML configuration when the daemon is starting up, but remove them from the trigger subs that get called regularly throughout its life? Well 95% of the time, best practice would just be to not worry about it. If memory's really tight, you probably shouldn't be writing your daemon in Perl in the first place :-) For those occasions where a particular scope is entered only once, and a lexical is set to be a long string, then undef before scope exit will free the space for that string, and undeffing a large lexical array will free 4*@array bytes on a 32-bit system. Dave.	[reply]