Re^3: Hash Search is VERY slow

> $ip4{pack "CC", $i0, $i1}{pack "CC", $i2, $i3} proves to be the most memory-friendly approach

This might be true for long keys, but the original strings of the keys are only stored once.

    
{192.168}{101.208}   :  69879492
...
{xC0xA8}{x65xD0}     :  69611776
[download]

that's a gain of ~0.3% °

I'd call this micro optimization, or did I miss something?

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery}

°) 0.383% to be more precise, so rather ~0.4%

Comment on Re^3: Hash Search is VERY slow Select or Download Code

Replies are listed 'Best First'.
Re^4: Hash Search is VERY slow by Tux (Canon) on Sep 30, 2021 at 11:54 UTC
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	[reply] [d/l] [select]
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]
Re^6: Hash Search is VERY slow by Tux (Canon) on Sep 30, 2021 at 13:07 UTC
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]
Re^7: Hash Search is VERY slow by LanX (Saint) on Sep 30, 2021 at 14:30 UTC
Re^6: Hash Search is VERY slow by soonix (Chancellor) on Sep 30, 2021 at 13:02 UTC
Hex octets have always the same length. Writing them in decimal, one often wants padding, which can inadvertently lead to octal notation.	[reply]