Sort IP List

Brian Milby brian at milby7.com
Sat Jun 30 13:03:53 EDT 2018


Here are some times on my system for comparison (100000 random IPs):

216% - ip2dec: 463 ms
190% - ip2decpvt: 407 ms
171% - ip2dec2: 366 ms
147% - ip2dec2pvt: 314 ms
200% - sortIPList: 427 ms --> original from Bob
100% - sortIPList2: 215 ms --> Alex's inline with constants
152% - sortIPList3: 325 ms --> numtobyte(item 1) &...
107% - sortIPList4: 230 ms --> bitOr instead of +
100% - sortIPList5: 214 ms --> item 4 of each + 256 * (...

sortIPList2 comes out fastest most of the time.  sortIPList5 does come out
ahead on some runs (Alex's alternate code).  I did all of this because I
was curious how the speed of using numtobyte would impact things.  It is
comparable to using a private function (ip2dec2pvt), but still slower than
inline.  While there I decided to also test the bitOr.


On Sat, Jun 30, 2018 at 5:10 AM, hh via use-livecode <
use-livecode at lists.runrev.com> wrote:

> Remains to remark that the upcoming standard IPv6
> with its text representations
> (Section 2.2 of https://tools.ietf.org/html/rfc4291)
> will require more detailed methods,
> both for number base conversion and for item sorts/cosorts
> (the items are hex numbers ...)
>
> @Bernd
> Depending on the function an inline computation (as Alex denoted)
> may be even faster than the private function calls?
> Here, with IPv4 addresses, it is faster.
>
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



More information about the use-livecode mailing list