[yyparm]

One lesson to take from this is that it's often worth spending an extra half hour or hour validating that your assumptions about where time is being spent are true.

I've seen two examples recently where a potentially impactful optimisation was added to a product but it didn't actually work as intended because of minor errors. It took a couple of years before the performance bugs were found, which required several hours of work.

In the first, a O(n) algorithm was replaced with a O(log n) version, but part of it remained O(n) for a subtle reason. The code was still faster by a constant factor so it wasn't totally obvious. In that case validating that the algorithm was actually O(log n) by doing some experiments for larger values of n would have revealed runtime was increasing linearly.

In the second, an optional argument was added to a method that triggered an optimisation for a particular case, but it was never passed in at any callsites. In that case many different tests could have revealed that the optimisation wasn't effective or that the new code wasn't even running.

[jacquesm]

> One lesson to take from this is that it's often worth spending an extra half hour or hour validating that your assumptions about where time is being spent are true.

That is the real takeaway from the article.

Making assumptions is fine, making assumptions and not immediately verifying whether they hold or not is not.

This is why it is super important to actually write down your assumptions and test them one-by-one when implementing some solution. More often than not you'll find that there is some light between what you thought was true and what is really happening.

So this is much more a systemic problem than just a database tuning problem.