in reply to RFC: Sorting IPv4 addresses

In practice, you often need the IP address in packed form anyway, so there's work reuse. That makes the solutions that pack that much more efficient.

If not, the following would be even faster 

unpack_ipv4s( sort { $a <=> $b } pack_ipv4s( @ips ) );

[download]

Where unpack_ipv4s and pack_ipv4s are efficient XS functions.

Of course, it would be even faster if you rewrote the sorter to work with numbers directly instead of handling SVs containing numbers.

It's curious that you only used unpack 'N' in combination with split and that you never tried split without unpack 'N'.

Replies are listed 'Best First'.
Re^2: RFC: Sorting IPv4 addresses
by bv (Friar) on Oct 07, 2009 at 01:33 UTC

    The packing and XS things are good points. My intended audience was the more casual user who would be uncomfortable implementing anything in XS (I'm only just barely dabbling in Inline::C, myself).

    As for split without unpack, I thought that was covered in the splitwise case, which I unabashedly stole from Understanding transformation sorts (ST, GRT), the details. Did you mean something else?

    print pack("A25",pack("V*",map{1919242272+$_}(34481450,-49737472,6228,0,-285028276,6979,-1380265972)))
[reply]
[d/l]
[select]

      As for split without unpack, I thought that was covered in the splitwise case

      No, that one doesn't pack

[reply]

        Ah, I see. That was another case of grabbing code from another node without checking enough. This code runs (by my benchmark) 33% faster than the old split_int:

        #...
split_pack => sub {
            my @sorted = map { join '.', unpack("CCCC", $_) }
                sort { $a cmp $b }
                map { pack("CCCC",split /\./) } @ips;
        },
#...

        [download]
        print pack("A25",pack("V*",map{1919242272+$_}(34481450,-49737472,6228,0,-285028276,6979,-1380265972)))
[reply]
[d/l]
[select]

In Section Meditations