http://qs1969.pair.com?node_id=309004


in reply to A (memory) poor man's <strike>hash</strike> lookup table.

Hi,

Congratulations, you just invented a kind of a Trie.

Besides that, you speak of a very serious problem (at least for us). And we're not that poor on memory. But Perl forces us to migrate some applications on 32GB RAM machines. Alas, they're 64bit and Perl is much more of a memory hog there than it is on 32bit. *sigh*

A less memory-hoggy Perl is on my wishlist for 5.10 and compare also this node of mine.

This problem has only one solution. A better implementation of hashes within perl - or at least some option where one can choose whether he'd like to trade memory for speed.

Again - I hope to see it in 5.10.

Bye
 PetaMem
    All Perl:   MT, NLP, NLU

Replies are listed 'Best First'.
Re: Re: A (memory) poor man's hash
by demerphq (Chancellor) on Nov 21, 2003 at 19:35 UTC

    Yeah it appears to be a hybrid Trie implementation. Which I personally find extremely amusing. The primary drawback with using Trie's is that they are typically terribly wasteful of memory. (Except if the data set is extremely dense.) Which is why it turns out that most times Tries are implemented they are implemented in a hybrid form, or are designed to work on a limited data set or both. OTOH one advantage of a pure Trie lookup is that a C implementation of the algorithm performs similarly or better than a hash lookup but does prefix matching as well.


    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi