Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: perl memory usage?
Message-ID: <7480@jpl-devvax.JPL.NASA.GOV>
Date: 20 Mar 90 19:30:33 GMT
References: <1990Mar19.210743.15896@chinet.chi.il.us>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 37

In article <1990Mar19.210743.15896@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
: Does perl release memory previously used by an associative array
: when you do %array = (); ?

Yes.

: I have a script that gathers data
: into a global array, then calls a subroutine that loads a similar
: local array with existing data from a file, then sorts the keys and
: merges the items back to the file.  At the end of the subroutine
: both arrays are set to ().  After many passes through this, the program
: slows to a crawl - should I be using undef %array or something else
: to release the data storage and hash table?  The keys for the array
: happen to be unique and thus not re-used by subsequent passes in case
: that matters.

Unique keys are no problem.  Not here anyway.  An undef should be
unnecessary.  In fact, the %array = () should be unnecessary on the
local array--Perl effectively does an undef when you exit the scope of
the local.

You should first of all check with ps to see if the process is actually
growing.  If it's not, you're barking up the wrong hash table.

If it is, you wouldn't perhaps be on one of those fun machines where
free() is a no-op?  If so, you might try Perl's malloc/free instead.
If that doesn't work, try defining the union overhead strut in malloc.c.

On the other hand, it might be something else you're doing that is
triggering some obscure bug.  Try to reduce it to a minimal test case.

It's also possible that your process is growing because somehow the %array = ()
is being ineffective (typographical error, or whatever).  But that should
only slow you down whenever it decides to double the size of the table--the
hash algorithm's speed is independent of the table size.

Larry