I work on an application with some serious performance issues. Nearly all of them involve some combination of:

- inefficient design around data dependencies and their identification

- redundant work performed around said dependencies

- excessive reliance on APIs for uses they’re not intended, which frequently causes…

- …excessive VM deoptimizations and excessive GC

Granted this is one application and I certainly don’t think it’s representative of anything. But it’s definitely a counterpoint to inefficient concurrency (where this app generally performs quite well).

Knowing WHEN to do BigO optimizations is part of knowing how to optimize. And for cases that _could_ ble NlogN, it may be perfectly fine to chose N^2 for moderate N, while N^3 can kill the solution.

As for timeouts, IO and deadlocks, those problems can also be a case of poor up front optimization (before codigng).

I find that big-O is exactly the performance problem that remains after you've tuned your IO, picked sensible timeouts, and eliminated deadlocks (which are straight-up bugs).

The things you list are the low-hanging fruit, after which most engineering teams throw their arms up and say "I guess we've gone as far as we can on this!"

It means you're mostly compute limited. Which i find is rare in web api's.

Big O can mean a lot of things. People often only think of BigO in terms of cpu cycles but it can be applied to memory and network just as easily.

Consider a piece of code that grabs a set of records and then loops over them to get an association for each one. I've seen this kind of code in code reviews from juniors. its a good starting point where I start showing them how to rewrite their sql call to get the associated record via join so it goes from O(n) network calls to O(1)

I find that problem kind of rare these days. Everybody knows about it.