in reply to Bidirectional lookup algorithm? (Updated: further info.)


Can you afford the memory footprint? If you have the RAM to spare, you should be getting O(1) lookups. On a Solaris box, I took your sample code and added another letter to get to most of 12 million entries for a memory footprint that was up in the 4 gigabyte class (3738M).

I'd expect that the hash implementation will be pretty time efficient compared to the alternatives, and it sounds like that's the main driver (assuming the RAM needs are not limiting).

  • Comment on Re: Bidirectional lookup algorithm? (Updated: further info.)

Replies are listed 'Best First'.
Re^2: Bidirectional lookup algorithm? (Updated: further info.)
by BrowserUk (Pope) on Jan 05, 2015 at 20:08 UTC

    The current hash lookups are very fast -- possibly as fast as I could hope to get -- the problem I'm trying to address is the memory consumed by the duplication of keys & values.

    As I said in the OP: "so the priority is the lookup speed -- preferably O(1) though O(logN) might be acceptable if the memory reduction was sufficient."

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.