[hu3]

> Maybe you can say that g(x) = 3n, in which case any f(x) that is O(3n) is really just O(n)...

In practice 3x operations can make a world of difference.

3x SQL queries, 3x microservice calls, missing batching opportunities, etc.

Sorry but this kind of theoretical reasoning wouldn't move a needle if I'm reviewing your PR.

[ryandv]

> Sorry but this kind of theoretical reasoning wouldn't move a needle if I'm reviewing your PR.

If this were a PR review situation I would ask for a callgrind profile or timings or some other measurement of performance. You don't know how your code will be optimized down by the compiler or where the hotspots even are without taking a measurement. Theoretical arguments, especially ones based on handwavey applications of big-O, aren't sufficient for optimization which is ultimately an empirical activity; it's hard to actually gauge the performance of a piece of code through mere inspection, and so actual empirical measurements are required.

[hu3]

Callgrind to measure impact of performing 3x more database queries or 3x more microservices calls?

I don't block PRs because of micro optimizations but my examples aren't.

[ryandv]

I recall looking at New Relic reports of slow transactions that suffered from stacked n+1 query problems because the ORM was obscuring what was actually going on beneath the hood at a lower level of abstraction (SQL).

My point is it's often difficult to just visually inspect a piece of code and know exactly what is happening. In the above case it was the instrumentation and empirical measurements of performance that flagged a problem, not some a priori theoretical analysis of what one thought was happening.