LPM: Not so quiet on the western front...

[Joe Hourcle]

It's a bit old, but well, I haven't been keeping up with this list, and it
seems to be an unresolved issue.


On Mon, 23 Jul 2001, Janine wrote:

> Nope, no evals.
>
> Here's the scoop:
>
> There's a huge select sorted by three fields.  The values in these three
> fields are affectionately known as a Big3.  We fetch rows, joining
> fields with a tab and pushing the resulting string onto an array, until
> the Big3 changes.  At that point, we do "stuff."  Then we undef the
> array and start fetching again.  There are about 900 different Big3s.
>
> undef @bigarray is not freeing up memory as I expect.  Watching the
> program's memory usage with top, it slowly creeps up and up and up -
> even after @bigarray is undef'd.
>
> Right now I'm looking at the "stuff".  Something in there must be
> holding on to elements in @bigarray.

Something similar went by the dc-pm list in June:


>===== Original Message From dc at lists.pm.org =====
> This was unexpected.  In the map method, I use the following line to
> declare my hashref to use to hold db fetch values:
>
> my $href = undef;
>
>
> even though I exit this method after each line and therefore $href should
> be automatically destroyed by GC, it's not.  However, changing that line
> to
>
> my $href = ();
>
> fixed the problem.  No idea what is going on here, though.
>
> --Curt


So, I don't know if it's absolutely similar, but you might try setting
your array to an empty list, instead of using undef, and see if that still
sucks down the same amount of memory.

-Joe