O expressions only show how an algorithm performance scales depending on the size of the data. They can't be manipulated as regular math expressions, and so O(NlogN) / O(N) != logN .

Undoing the tipical simplifications performed to get to the O expression, we can obtain a valid expression for the number of operations required by an algorithm. For instance, for an O(NlogN) algorithm as perl built-in sort, the number of operations should be something like A*NlogN + B*N + C (where A, B and C are unknown constants).

For an O(N) algorithm the number of operations is usually B'*N + C'. But when sorting using the ST the cost of the algorithm is still O(NlogN), you can not ignore the sort step, even if it is implemented in fast C. So the real number of operations is A'*NlogN + B'*N + C', though A' is much smaller than A.

Considering all this, the resulting relative performance between both algorithms is (A*NlogN + B*N + C)/(A'NlogN + B'*N + C)

It's very different from the logN value you were using and that's why the benchmark results don't mach your expectations.