in reply to RAM: It isn't free . . .

Since your post probably came from reading BrowserUk's question about Bidirectional lookup algorithm, let's put your theory to the test with the method he used:

use Devel::Size qw/total_size/; $h{$_} = 1 for "aaaaa".."zzzzz"; $elements_size += total_size $_ for %h; $hash_size = total_size \%h; print <<INFO; Total size of the contained elements: $elements_size Total size of the hash: $hash_size INFO __DATA__ Total size of the contained elements: 1223781728 Total size of the hash: 1167897536
It sure looks like I did something wrong. But since keys are constant strings (of fixed size), they probably take less space than a string in a scalar (scalar have all sorts of additional information, and a bit of extra space to avoid constant reallocation), so in the end I don't think I made any mistakes here. And I'm saying "probably" because I didn't check in the guts.

A lot of data in a hash sure takes a lot of memory, same goes for arrays because a lot of data will take a lot of memory unless it's properties allow for a very effective compression. If you only use pure perl, trying to avoid a hash because they are "bad" has very high probability of just being worse (hashes are an excellent compromise between algorythm complexity and memory consumption).

Replies are listed 'Best First'.
    A reply falls below the community's threshold of quality. You may see it by logging in.