4 ms·
I don't think it's a critique of writing performant code. I always took it to mean don't optimize your code before you know where the bottlenecks are. For examp
by okareaman 6y ago
I don't think it's a critique of writing performant code. I always took it to mean don't optimize your code before you know where the bottlenecks are. For example, I could spend a lot of time on a Boyer Moore string matching algorithm only to find later that my program actually spends very little time searching strings.
- Gibbon1 6y agoI think of that quote as being in the context of the sorts of 'music box' programs people were writing in the 1970's. This little gear also has a cam that operated the ballerina's arm. It's the sort of thing you do when you need to stuff a FORTRAN compiler in 32k of memory. If you write your code right then refactoring it to use a different more whatever algorithm should be if not easy at least 'not hard'.
- qes 6y ago> I could spend a lot of time on a Boyer Moore string matching algorithm Could you? It's like an hour to copy/paste a reference implementation and set up unit tests. Maybe an hour or two fine tuning the implementation for your language and benchmarking some use cases. I'd been using the same C# Boyer-Moore impl for like 15 years, and happened to have just recently updated it for Span support. I doubt I have 8 hours into it in total, and it's thoroughly benchmarked and tested.
- okareaman 6y agoYou're missing my point. Pick coding up something that for you would be an egregious waste of your time on this earth.