4 ms·
The advice doesn't generalize to high level "optimizations". The problem with optimizations (low level) is they make the code more complicated and more difficul
by hsn915 5y ago
The advice doesn't generalize to high level "optimizations". The problem with optimizations (low level) is they make the code more complicated and more difficult to understand. This is a problem. You better have really good payout. (It also takes a lot of time to apply micro optimizations to everything, so if you agonize about every CPU instruction you will never get anything done).
But, general high level design decisions that don't produce slow code by default do not suffer from this. They don't make the code any complicated or hard to understand. Quite the opposite, they usually simplify things. Because most of the time, the way to get good performance is to do the minimal thing that needs to be done to perform the task at hand. The code you write will be very straight forward. There's no switching cost.
On the other hand, choosing a slow language has a high switching cost. You can't just take a bad design and try to optimize it. It usually doesn't work. You have to rework the whole design.
EDIT:
I have one other important point to add:
> Applying optimizations before knowing where a bottleneck is just a bad idea, regardless of the situation.
Ignoring any and all performance concerns using this kind of reasoning will result in a codebase that is permeated with slowness. The program is slow but you can't identify any single bottleneck. You end up with a monster that simply can't be fixed.
Worse, you may not even realize how slow it actually is. If you have profiled it and found no particular bottle neck, you may think this simply the limit of computer performance and the task at hand cannot be performed any faster than this.
- taeric 5y agoI love that you can replace "optimization" in your first paragraph with "abstraction" and have the same results. :D This actually leads me to see the concept of "micro abstractions", and I'm going to see if I see those in hard to deal with programs, now.
- hsn915 5y agoI'm not sure what you mean, but with abstraction it's the opposite of what I said. Premature abstraction really is very very bad (I won't go so far as to say it's the root of all evil). The higher level the abstraction, the worse it is. Unless it's born from experience writing the same kind of program many times. In which case it's not "premature". "micro abstractions" are actually fine. You notice a recurring pattern in the code so you "abstract" it away into a function.
- taeric 5y agoMy guess is we are talking of different things when envisioning micro abstractions. I have in mind the projects that went from a handful of data structures and functions to dozens of each. Typically in the vein of abstracting away whatever immediate problem was faced in the code. Have a workflow? Make a workflow abstraction that can run any work. Have code that needs to retry? Make a retry facility that can retry for any reason. Than make a grammar to specify what backoff should be used. While doing those, realize you want a rules engine to determine what work and what backoff to use. Then, put in a sat solver. To determine if a plan can be done. ... None of these are really bad things, in and off themselves. Odds are high they would all be poorly done, or themselves a giant undertaking.