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@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@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode