in reply to Sorting a list of IP addresses (aka Why I hate Big O)
The BigO notation doesn't work in such a simple way as
taking the complexity of two algorithms and comparing them
directly like that. BigO notation relies heavily on
exactly what 'N' is. Just because two algorithms are O(N)
or O(N^2) doesn't mean a thing, because in one algorithm,
N could be a large, timeconsuming mathematical calculation,
and in the other N could be a simple regular expression.
The power of BigO notation comes with being able to roughly
be able to predict how an algorithm will act on different
sizes of datasets, and taking that information and tailoring
your algorithm to get the best performance based on the
fastest running time of the averagesized set of data. If
one algorithm is O(N), and the other is O(N^2), the latter
may be a better choice in some cases, if the former has a
much larger N, and you can ensure that there won't be too
much data to negate the smaller N.
Basically, it all boils down to the necessity of doing much
more testing than you did. The best efficiency takes many
steps to reach. If you did more benchmarks with different
numbers of IP addresses, different complexity algorithms,
and things like that, you'd start to see how the BigO
notation would help you predict future tests.
RE: RE: Sorting a list of IP addresses (aka Why I hate Big O) by tilly (Archbishop) on Aug 08, 2000 at 01:07 UTC 
There is a very interesting point about Perl and algorithmic efficiency. Perl makes it very natural for people to use highly optimized pattern recognition algorithms in the regular expression engine, and a good hashing algorithm.
C, while much faster, makes it far more natural to repeatedly scan lists rather than store a key in a hash and just check exists.
The result is that the same person in many circumsances will find that their Perl code not only is easier to write and read, but outperforms what they would have written in C. Sure, if they wrote their C carefully they would beat Perl every time. But natural Perl idioms tend to be better algorithmically than the natural C approaches, and algorithmic efficiency trumps raw performance.
(This does not hold true for all programmers, YMMV, etc. But it is surprising how often it is true.)  [reply] 
