Why analyse an algorithm by counting operations instead of just measuring how many milliseconds it runs?
A measurement describes one machine on one input; an operation count describes the algorithm itself, which is the only thing you can carry to another machine or a bigger input.
Timing has three problems that counting does not:
- It measures the wrong thing. A stopwatch measures your CPU, your compiler, your JIT warm-up, what else the OS was doing. Change any of those and the number changes, while the algorithm did not.
- It only covers the inputs you tried. The interesting behaviour is what happens as the input grows, and you cannot try all sizes.
- It needs an implementation. Counting works on pseudo-code, so you can compare two designs before writing either one.
Counting gives a function of the input size, e.g. $8n - 2$, and a function can be extrapolated: it predicts the shape of the curve at sizes you never measured. That predictive power is the point of the whole exercise — asymptotic analysis is about the trend, not about any single number.
Measurement still has a job — it is how you confirm the predicted shape actually shows up in the real implementation — but it is the check, not the analysis.
Go deeper:
MIT 6.100L — Big Oh and Theta (Ana Bell) — a full lecture on describing growth independently of machine and implementation.