Re^4: Hash Search is VERY slow

[Tux]

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.

[LanX]

> 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?

[Tux]

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

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

[LanX]

OK thanks, I see.

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

[soonix]

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