One of the fringe benefits of being a programmer is that if you try, you can start developing an intuition for how things across a huge span of orders of magnitude add together. That chart alone covers 8-and-a-bit orders of magnitude differences for simple operations, and then we may want to perform those operations thousands or billions or quadrillions of times.
I don't do super-high-performance systems, but I still encounter coworkers in our normal routines who are off in the mental models by multiple orders of magnitude w.r.t. to how much something should cost. I see overestimation more often than underestimation.
(My opinion on that is that if you "think" a database query should take 50ms, when it actually does you don't worry about it and dig into why. When the answer is, you're missing an index and doing a table scan for something that ought to be 5 microseconds, a full 4 orders of magnitude difference, it's easy to not notice, because in absolute, human terms, 50ms is still pretty fast. Make a dozen or two of those mistakes, even in otherwise very large systems running lots of code with a lot more than a dozen things going on, and it's easy for overestimates to become self-fulfilling prophecies and to accidentally build systems bleeding out orders (plural!) of magnitude performance without realizing it. Underestimates are much more likely to slap you in the face and get resolved one way or another.)
Another example: I'm a fan of time-tested wisdom of all sorts, but sometimes time does move on and invalidate things. "It all adds up" used to be true when everything we humans dealt with was in the same rough orders of magnitude, but it's not always true anymore. It doesn't always all add up. If I've got a 500ms process, do you have any idea how many nanosecond things it takes to even bump that by 1%, let alone add up to anything significant? If your "1ns"-range code has effectively no loops, or is O(n) on some small chunk of data or something, it's inconsequential. There's plenty of other places in the modern world, which spans more orders of magnitude than the world used to, where this time-tested wisdom can be false, and it in fact does not "all add up".
This is one of the reason you must always profile your code if you want to improve performance. People have always not always been perfect at finding bottlenecks even when our machines didn't casually span 12 orders of magnitude, but any developer no matter how experienced can be tempted to blame the complicated code dealing in microseconds but miss the simple-looking code hiding milliseconds.
This covers mostly the first bit of the article, but if you practice this sort of sense can start helping with a lot of the other innumeracy issues encountered too. We have good practice grounds for this in our discipline.
Is all adds up still. Just some “its” add up to a lot more than others.
I agree with your point. I’ve spent way too much time responding to code reviews where the reviewer asks me to be more efficient in something that takes triple digit nanoseconds per request on internal systems that typically get dozens of requests per day.
I would love a version of this classic xkcd that covers events that take nanoseconds and milliseconds [0]. I suppose it would have to also account for the difference in value between a human’s time and a machine’s unless you assume there is a human waiting in real time for every process to finish.
One of the fringe benefits of being a programmer is that if you try, you can start developing an intuition for how things across a huge span of orders of magnitude add together. That chart alone covers 8-and-a-bit orders of magnitude differences for simple operations, and then we may want to perform those operations thousands or billions or quadrillions of times.
I don't do super-high-performance systems, but I still encounter coworkers in our normal routines who are off in the mental models by multiple orders of magnitude w.r.t. to how much something should cost. I see overestimation more often than underestimation.
(My opinion on that is that if you "think" a database query should take 50ms, when it actually does you don't worry about it and dig into why. When the answer is, you're missing an index and doing a table scan for something that ought to be 5 microseconds, a full 4 orders of magnitude difference, it's easy to not notice, because in absolute, human terms, 50ms is still pretty fast. Make a dozen or two of those mistakes, even in otherwise very large systems running lots of code with a lot more than a dozen things going on, and it's easy for overestimates to become self-fulfilling prophecies and to accidentally build systems bleeding out orders (plural!) of magnitude performance without realizing it. Underestimates are much more likely to slap you in the face and get resolved one way or another.)
Another example: I'm a fan of time-tested wisdom of all sorts, but sometimes time does move on and invalidate things. "It all adds up" used to be true when everything we humans dealt with was in the same rough orders of magnitude, but it's not always true anymore. It doesn't always all add up. If I've got a 500ms process, do you have any idea how many nanosecond things it takes to even bump that by 1%, let alone add up to anything significant? If your "1ns"-range code has effectively no loops, or is O(n) on some small chunk of data or something, it's inconsequential. There's plenty of other places in the modern world, which spans more orders of magnitude than the world used to, where this time-tested wisdom can be false, and it in fact does not "all add up".
This is one of the reason you must always profile your code if you want to improve performance. People have always not always been perfect at finding bottlenecks even when our machines didn't casually span 12 orders of magnitude, but any developer no matter how experienced can be tempted to blame the complicated code dealing in microseconds but miss the simple-looking code hiding milliseconds.
This covers mostly the first bit of the article, but if you practice this sort of sense can start helping with a lot of the other innumeracy issues encountered too. We have good practice grounds for this in our discipline.