5 ms·

Ya that paragraph is ripe for cherry picking that often quoted nugget. But right after it is "we should not pass up our opportunities in that critical 3%". And

Ya that paragraph is ripe for cherry picking that often quoted nugget. But right after it is "we should not pass up our opportunities in that critical 3%". And further along, "the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail." That one I think is the most important. You don't even know what you should optimize until you measure. You could end up spending a lot of time and energy on the wrong problem.

Brian_K_White 4y ago
It's like the problem is the ambiguous definition of "premature". I think by itself the phrase is taken to mean to keep the code high level and abstract as long as it might still need to change, and then only optimize once it's overall structure is established, because once you start optimizing for performance you are carving stone and destroying flexibility. But the full context shows that the word "premature" in this context means to say that it's premature to optimize before you even know what to optimize.
ncmncm 4y ago
Those of us who have been doing this a long time develop an awareness of our "hot path", and defend it against encroachments. Work keeping speed bumps out of our hot path is not premature.
jandrewrogers 4y ago
Performance is not a primary objective for most software. For the subset where it is, most performance is architectural; if you don't design for performance from the outset then you'll never be able to add it later. People that have been in the performance business a long time, the kind of people you want if performance matters, can estimate the performance of code without running it to a degree of accuracy that is surprising to people with no performance engineering experience. Not understanding the relationship between code and performance is not the same as no one being able to understand the relationship between code and performance. It is a specialized discipline but people in it don't need to measure code for macro-optimization purposes. You still need to measure some things for micro-optimization purposes, but even there you'll find savants that really don't need to. Naturally, there is an element of many developers overestimating their ability to estimate code performance. That is not universal though. I've worked with developers that could consistently and precisely describe the performance characteristics of code on real hardware without running it. A lot of computer science is premised on this being possible. Acting like this is unknowable is doing a disservice to computer science as a discipline. If you understand how code interacts with hardware then performance is deterministic and obvious. There are degrees, of course, but some developers have a deeply intuitive understanding of these relationships.
- vlovich123 4y ago
  > For the subset where it is, most performance is architectural; if you don't design for performance from the outset then you'll never be able to add it later. This conclusion is strange to me. Literally every performance improvement I’ve seen is done at the end of a project. Of course you try to avoid architectural defects, but software is not immutable. So you punt the performance work later in the cycle once a) you’ve verified the approach overall roughly works b) you’re confident you have a handle on the business needs c) you have identified a need to improve performance. Any performance defects that turn out to be architectural in nature are still fixable, just more expensive (hence the desire to fix the most obvious ones). For example, look at any piece of Google infrastructure. They always go through several iterations because it doesn’t matter how good your intuition may be. You can still be wrong and the landscape isn’t static so whatever was right at the time may have evolved to not be as right. For example, protobufs made the right choice about encoding for space when bandwidth was more limited. Now that bandwidth is much more free and compression is more effective, it’s better to use compressors instead of trying to find a more optimal binary coding.
  - citrin_ru 4y ago
    Of course it is not the best use of time to optimize from day one if there is no need to have this piece of software to be fast/efficient, but if performance is an important requirement it's too late to add it at the end. You cannot optimize Apache 1.x to handle 1M concurrent connections and 1M request per second (without rewriting it more or less fully). Nginx can handle such load on a single modern server because attention to performance (efficiency) was paid from the start of development. If performance is awful to begin with you can improve it visibly by fixing a few hot-spots (like unnecessary O(N^2) for N which can be large). But when I do profiling for software which is not too bad to begin with there usually no single place which can be changed to give statistically significant improvement - there are many comparably slow places. One can try to improve them piece by piece but sooner or later abstractions will get in the way and if performance is still not enough you'll need to start from scratch keeping performance in mind.
    - 4y ago

Brian_K_White 4y ago

It's like the problem is the ambiguous definition of "premature". I think by itself the phrase is taken to mean to keep the code high level and abstract as long as it might still need to change, and then only optimize once it's overall structure is established, because once you start optimizing for performance you are carving stone and destroying flexibility. But the full context shows that the word "premature" in this context means to say that it's premature to optimize before you even know what to optimize.

ncmncm 4y ago

Those of us who have been doing this a long time develop an awareness of our "hot path", and defend it against encroachments. Work keeping speed bumps out of our hot path is not premature.

jandrewrogers 4y ago

Performance is not a primary objective for most software. For the subset where it is, most performance is architectural; if you don't design for performance from the outset then you'll never be able to add it later. People that have been in the performance business a long time, the kind of people you want if performance matters, can estimate the performance of code without running it to a degree of accuracy that is surprising to people with no performance engineering experience. Not understanding the relationship between code and performance is not the same as no one being able to understand the relationship between code and performance. It is a specialized discipline but people in it don't need to measure code for macro-optimization purposes. You still need to measure some things for micro-optimization purposes, but even there you'll find savants that really don't need to. Naturally, there is an element of many developers overestimating their ability to estimate code performance. That is not universal though. I've worked with developers that could consistently and precisely describe the performance characteristics of code on real hardware without running it. A lot of computer science is premised on this being possible. Acting like this is unknowable is doing a disservice to computer science as a discipline. If you understand how code interacts with hardware then performance is deterministic and obvious. There are degrees, of course, but some developers have a deeply intuitive understanding of these relationships.

vlovich123 4y ago
> For the subset where it is, most performance is architectural; if you don't design for performance from the outset then you'll never be able to add it later. This conclusion is strange to me. Literally every performance improvement I’ve seen is done at the end of a project. Of course you try to avoid architectural defects, but software is not immutable. So you punt the performance work later in the cycle once a) you’ve verified the approach overall roughly works b) you’re confident you have a handle on the business needs c) you have identified a need to improve performance. Any performance defects that turn out to be architectural in nature are still fixable, just more expensive (hence the desire to fix the most obvious ones). For example, look at any piece of Google infrastructure. They always go through several iterations because it doesn’t matter how good your intuition may be. You can still be wrong and the landscape isn’t static so whatever was right at the time may have evolved to not be as right. For example, protobufs made the right choice about encoding for space when bandwidth was more limited. Now that bandwidth is much more free and compression is more effective, it’s better to use compressors instead of trying to find a more optimal binary coding.
- citrin_ru 4y ago
  Of course it is not the best use of time to optimize from day one if there is no need to have this piece of software to be fast/efficient, but if performance is an important requirement it's too late to add it at the end. You cannot optimize Apache 1.x to handle 1M concurrent connections and 1M request per second (without rewriting it more or less fully). Nginx can handle such load on a single modern server because attention to performance (efficiency) was paid from the start of development. If performance is awful to begin with you can improve it visibly by fixing a few hot-spots (like unnecessary O(N^2) for N which can be large). But when I do profiling for software which is not too bad to begin with there usually no single place which can be changed to give statistically significant improvement - there are many comparably slow places. One can try to improve them piece by piece but sooner or later abstractions will get in the way and if performance is still not enough you'll need to start from scratch keeping performance in mind.
  - 4y ago