Using each on a lookup instead of hash ref?

1 view
Skip to first unread message

QM

unread,
Oct 15, 2009, 5:47:19 PM10/15/09
to DBM-Deep
[I tacked this onto the reply about Git, but it probably went
unnoticed, so I'm starting a new thread...]

I was rereading the docs the other day, and came across the
warning about using each on an a lookup instead of a hash ref:

Please note that when using each(), you should always pass a
direct hash reference, not a lookup.

Is this still accurate? I say that because I tried changing to the
hash ref, and the preliminary conclusion is that it doesn't make any
difference.

I thought about moving to the first_key/next_key form, but this
wouldn't work on in-memory hashes (when I choose not to use the DB),
and I'd have to code up something like this (untested):

my $key;
if ($using_dbm_deep) {
$key = $hash{some_key}->first_key() if $using_dbm_deep;
} else {

$key = each %{$hash{some_key}};
}

while ( $key )
{
do stuff with $key

} continue {

if ($using_dbm_deep) {
$key = $hash{some_key}->next_key($key);
} else {
$key = each %{$hash{some_key}};
}

}

Or maybe something like this already happens for me when I use each on
a D::D object?

QM

unread,
Oct 28, 2009, 11:25:27 AM10/28/09
to DBM-Deep
After running a few big jobs with this change, I still see that
walking the hash takes longer and longer the more keys are accessed.
For example, at the start, the first 100 keys took 80sec to access and
output (<1sec/key), while 100 keys around the 72K mark took 300sec
(3sec/key). This seems to progress quite steadily from start to
finish.

The output is just normal text piped to gzip. Other processes running
don't seem to phase it (4 cpu system, lots of memory). I can only
suggest that this is some kind of disk access problem.

Any other suggestions?

Rob Kinyon

unread,
Oct 28, 2009, 11:34:29 AM10/28/09
to dbm-...@googlegroups.com
Patches welcome. I don't have the time to work on it. :(

Actually, i'd love to have a few co-maintainers. Anyone who wants a
comaint bit, let me know.

Rob
--
Thanks,
Rob Kinyon
Reply all
Reply to author
Forward
0 new messages