4 ms·

The optimisation story reminds me of tuning databases and associated apps. Often a bunch of ~5% improvements add up to 50% or more. This can be surprising to pe

The optimisation story reminds me of tuning databases and associated apps. Often a bunch of ~5% improvements add up to 50% or more. This can be surprising to people that individually “pointless” improvements can result in a dramatic end result. For example, if a common update transaction occurs once a second and takes 1.1 second, then the transactions from different users will overlap in time, possibly blocking each other on locks. Speeding up something like this just a little bit will drop the time to 0.9 seconds, reducing the percentage chance of overlap significantly. That has a compounding effect so the queries might suddenly take 0.5 seconds due the lack of lock contention! There are similar effects due to sharing of CPU caches when queries run concurrently. Even if they’re independent, the hardware isn’t! Getting to the point that they all run in isolation might not take much effort, but yield dramatic benefits.

BiteCode_dev 4y ago
For the same reason, the ROI on vertical scaling is very good, and buying a bigger server is a lot of the time a very cheap and good way of solving a problem.
hinkley 4y ago
The other issue he didn’t talk about was how bad we are at fractions, or what I usually call budget based tuning. What I’ve seen over and over is people who won’t look at single digit percentage improvements because those aren’t “enough”. But the thing is that if you are trying to cut time in half, the 6% for that one method is 12% of your target. So they’re optimizing the way some people do personal finances. Some of them get “there” in the end, but the road they take is longer and ineffective. When you are looking at four slow methods in a particular flow, you have the perspective of seeing them as parts of a whole. Maybe there’s a way you can rewrite these 4 methods into three that do less, or five where we avoid work in the common case. If you do them one at a time, and prioritize new ones as they cross your artificial and inaccurate threshold. you won’t see these options, and if you do you’ll talk yourself out of it because you already spent a bunch of effort on what you have now (sunk cost).

BiteCode_dev 4y ago

For the same reason, the ROI on vertical scaling is very good, and buying a bigger server is a lot of the time a very cheap and good way of solving a problem.

hinkley 4y ago

The other issue he didn’t talk about was how bad we are at fractions, or what I usually call budget based tuning. What I’ve seen over and over is people who won’t look at single digit percentage improvements because those aren’t “enough”. But the thing is that if you are trying to cut time in half, the 6% for that one method is 12% of your target. So they’re optimizing the way some people do personal finances. Some of them get “there” in the end, but the road they take is longer and ineffective. When you are looking at four slow methods in a particular flow, you have the perspective of seeing them as parts of a whole. Maybe there’s a way you can rewrite these 4 methods into three that do less, or five where we avoid work in the common case. If you do them one at a time, and prioritize new ones as they cross your artificial and inaccurate threshold. you won’t see these options, and if you do you’ll talk yourself out of it because you already spent a bunch of effort on what you have now (sunk cost).