In theory it should be possible to approximate O(n) by benchmarking for increasing n and using numerical methods to interpolate the gotten data.

In praxis a human should define what exactly "n" is, the accuracy of the interpolation ( O(1) and O(log log n) can look very similar ;) and when to stop testing... with "enough" time for testing you'll certainly get a result...

But you can tell that a program didn't finish after a given threshold (a week or so) without violating Turing's laws.

Yes, that's an incomplete solution. Which doesn't tell you anything about the asymptotic runtime if it didn't finish.

In theory it should be possible to approximate O(n) by benchmarking for increasing n and using numerical methods to interpolate the gotten data.

If you don't try it for all possible inputs you can miss worst case scenarios.

For example old versions of perl used to have an O(n) complexity for hash accesses if the keys followed a certain pattern that lead to 100% hash collisions - which was an attack vector for denial of service attacks.

(Newer perl versions solve that by randomizing hash seeds if too many collisions occur).

You not only have to specify what n in O(n) means, but also if you're talking about worst case, average case or amortized runtime.

Well it's only approximation and as I said implies waiting for "enough" time. I doubt that waiting for weeks is considered practicable for a reasonable accuracy of the numerical calculations! (since these calculations rely on leveraging effects of multiple runs 8 )

(OTOH the sheer fact that you have to wait too long already gives you information that the tested algorithm might not be what you wanted).

But you're right, worst case complexity is far less practicable, because this implies checking _all_ cases. And worst case is what you normally want to be expressed by the Landau symbol.

Cheers Rolf