Re: Memory query

[Andrew Green]

In article [EMAIL PROTECTED],
   Perrin Harkins [EMAIL PROTECTED] wrote:

 If you actually want to free the memory, you need to undef it.  The
 untie prevents it from persisting, but the memory stays allocated
 unless you undef.

OK, I think I'm probably handling this properly then, after all.
In a Registry script, I typically tie the hash to a package global, and
pass a reference to that hash to any routines in my library modules.  At
the end of the script, the hash is untied and the package global undefed.

Many thanks,
Andrew.

-- 
perl -MLWP::Simple -e 'getprint(http://www.article7.co.uk/res/japh.txt;);'

Re: Memory query

[Perrin Harkins]

Andrew Green wrote:
 In particular, I'm
 looking for reassurance that passing a reference to a hash doesn't copy
 the hash itself into memory in any way, and that the memory overhead is
 only as large as the largest $item.

That's basically correct, but some dbm implementations will use their 
own caching and that may increase this overhead.

 Similarly, if I was to
 
  use vars(%hash);
 
 and initialise the tied hash as a global, does this have a significant
 memory overhead?

No, it's the same except for the addition of an entry in the symbol table.

 Does untie-ing the hash clear the hash contents from
 memory, or do I also need to undef the hash to avoid the hash contents
 persisting from one request to the next?

If you actually want to free the memory, you need to undef it.  The 
untie prevents it from persisting, but the memory stays allocated unless 
  you undef.

 Is one approach better than the
 other?

Not in terms of memory.  The thing you need to think about with regard 
to dbm files is how to make sure they are synchronized between multiple 
processes.  You basically just need to untie them after each request 
(unless it's read-only data).  By the way, MLDBM::Sync takes care of all 
of that for you.

- Perrin