4 ms·

This article makes a strange assumption. That you know perfectly the end result before starting the process, which is a rare case in my experience. Normally, a

This article makes a strange assumption. That you know perfectly the end result before starting the process, which is a rare case in my experience. Normally, a product will start with a small feature, and all sorts of random stuff will be added to it to make it grow. Some of them will be abandoned, as they'll fail commercially, and some will expand as they bring money or attention. Creating an architecture that can allow that kind of expansion without crumbling over tech debt is the challenge. Ultimately, some programs can be reduced to a simple operation, and that can be designed from the ground up to be really performant. Something like the silver searcher (https://github.com/ggreer/the_silver_searcher https://github.com/ggreer/the_silver_searcher) or ripgrep (https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep) have the advantage that they have laser-focus in what they want, and designed to take advantage of that. Most of the developed software have way broader objectives. The important part of "premature optimisation is the root of all evil" is PREMATURE. Don't optimise things that is still uncertain that required to be optimised. When performance is critical OF COURSE optimisation is a requirement.

hashkb 7y ago
There's a middle ground. I like to say "fast is a feature" or "it's not done til it's fast". Getting the feature working is a first step, but shipping a slow feature is never ok.
gwd 7y ago
> The important part of "premature optimisation is the root of all evil" is PREMATURE. Right -- I think the examples he's arguing against have slightly misunderstood what "premature" means. The quote is supposed to mean, "Don't optimize until you know that optimization is necessary." The people in his examples are interpreting it as, "Don't optimize until your program is feature complete". I doubt Knuth would agree with that principle. If people are raising tickets saying that some feature is slow, then you know optimization is necessary, and it's not premature any more. That said, as with any proverb, you have to use some common sense. If you know you're going to be doing key-value lookups in a data structure that's going to contain hundreds of thousands of pairs, it's OK to start off with a hash table, rather than starting with flat list + linear search and switching over only after benchmarking.

hashkb 7y ago

There's a middle ground. I like to say "fast is a feature" or "it's not done til it's fast". Getting the feature working is a first step, but shipping a slow feature is never ok.

gwd 7y ago

> The important part of "premature optimisation is the root of all evil" is PREMATURE. Right -- I think the examples he's arguing against have slightly misunderstood what "premature" means. The quote is supposed to mean, "Don't optimize until you know that optimization is necessary." The people in his examples are interpreting it as, "Don't optimize until your program is feature complete". I doubt Knuth would agree with that principle. If people are raising tickets saying that some feature is slow, then you know optimization is necessary, and it's not premature any more. That said, as with any proverb, you have to use some common sense. If you know you're going to be doing key-value lookups in a data structure that's going to contain hundreds of thousands of pairs, it's OK to start off with a hash table, rather than starting with flat list + linear search and switching over only after benchmarking.