in reply to Re^3: Hash Search is VERY slow
in thread Hash Search is VERY slow

Your suggestion of using {"192.168"}{"101.208"} is indeed almost as small as my pack version, so it shows close to no gain in memory. Both are however 40% smaller than the original {"192.168.101.208"}.

I just included all of those to show the differences in size.

I first thought I'd use Socket::inet_aton, but that of course does not support the {A.B}{C.D} split.

The win in using pack over plain is not the .3% gain in memory size, but the ease of sorting.


Enjoy, Have FUN! H.Merijn

Replies are listed 'Best First'.
Re^5: Hash Search is VERY slow
by LanX (Saint) on Sep 30, 2021 at 11:59 UTC
    > The win in using pack over plain is not the .3% gain in memory size, but the ease of sorting.

    I'm confused ... when do I need to sort hash keys?

    And why is it "easier" to sort the packed version of "023.156" ? Do you mean faster?

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

[reply]
[d/l]

      I sort hash keys all the time. And IP sorting is easy when you include leading zeroes as you just did, but most IP's I see in log files are without leading zeroes, so ordering them would result in

      1.2.3.4
10.2.3.4
104.2.3.4
11.2.3.4
2.2.3.4
23.2.108.4
23.2.3.4
23.2.30.4
23.2.4.4

      [download]

      and IMHO that sucks. Using packed keys sorting is always correct. If it is faster? No idea, Icould bench that, but I expect it to be marginal

      Side note: I *always* sort hash keys in tests, as order is randow


      Enjoy, Have FUN! H.Merijn
[reply]
[d/l]
        OK thanks, I see.

        was confused b/c the thread was about "slowness".

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

[reply]
      Hex octets have always the same length. Writing them in decimal, one often wants padding, which can inadvertently lead to octal notation.
[reply]

In Section Seekers of Perl Wisdom