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;);'

Memory query

[Andrew Green]

Morning all,

Forgive the naivete, but I'm having trouble wrapping my mind around the
memory implications of using tied hashes, and I haven't found anything in
the Camel book or the Guide to clarify the situation for me.

A fair amount of my Registry scripts need to use code not unlike the
following:

use strict;
use Fcntl;
use MLDBM qw(DB_File Storable);

[...]

tie(my %hash, 'MLDBM', $filename, O_RDONLY, 0644)
or die Denied $filename: $!\n;

foreach my $item (keys %hash) {
   action(\%hash,$item);
}

untie %hash;

I'm intrigued about the memory implications of this kind of construction
where the MLDBM hash is potentially very large.  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.

Similarly, if I was to

 use vars(%hash);

and initialise the tied hash as a global, does this have a significant
memory overhead?  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?  Is one approach better than the
other?

As I said, my apologies for the newbieness of all this, and even bigger
apologies if it represents an FAQ that I've missed spotting.

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