4 ms·

I kind of dislike this quote because performance matters a great deal and it should be a design goal before code is even written imo which I guess would be as “

by klysm 6y ago

I kind of dislike this quote because performance matters a great deal and it should be a design goal before code is even written imo which I guess would be as “premature” as possible

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 ago
  I 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 ago
    You're missing my point. Pick coding up something that for you would be an egregious waste of your time on this earth.
db48x 6y ago
It's one thing to design a program such that it can be fast, and quite another to focus on some random piece of code and spend weeks optimizing it, only to find out later that the performance of that particular piece of code was irrelevant.
AnHonestComment 6y ago
Early isn’t necessarily premature. I always took the quote to mean you should focus on the right optimizations at the right time — starting with architectures and algorithms that alleviate as much work as possible (big savings) and only then get into code level optimizations (small savings). Architecture and algorithm design is where you get your “big O” wins, while code optimizations get you that last scaling factor of efficiency. It’s a retort to people who micro-optimize an HTTP response... while having a process that generates 10x the API calls it needs to by not caching or joining data.

by klysm 6y ago

I kind of dislike this quote because performance matters a great deal and it should be a design goal before code is even written imo which I guess would be as “premature” as possible

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 ago
I 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 ago
  You're missing my point. Pick coding up something that for you would be an egregious waste of your time on this earth.

db48x 6y ago

It's one thing to design a program such that it can be fast, and quite another to focus on some random piece of code and spend weeks optimizing it, only to find out later that the performance of that particular piece of code was irrelevant.

AnHonestComment 6y ago

Early isn’t necessarily premature. I always took the quote to mean you should focus on the right optimizations at the right time — starting with architectures and algorithms that alleviate as much work as possible (big savings) and only then get into code level optimizations (small savings). Architecture and algorithm design is where you get your “big O” wins, while code optimizations get you that last scaling factor of efficiency. It’s a retort to people who micro-optimize an HTTP response... while having a process that generates 10x the API calls it needs to by not caching or joining data.