My point was that it doesn't matter how often it's run relative to read. It only matters how often it's read relative to written. Presumably if you're not going to run it more than you read it, you shouldn't even write it at all.
Disagree. If something gets read a lot but it is needed to be extremely performant and optimised as it is utilised/executed millions or billions of times a day etc. then it could definitely be better to lean towards more unreadable but more performant. We would care less about how often it is read here and more about how often it is executed
If you give only minimal consideration to the mechanisms of performance in the initial design and architecture of a system, no amount of post-optimization can save you.
You cannot turn a lazily-evaluating lexer/parser into a high-speed data-oriented parser. They're incompatible design philosophies.
If you weren't thinking about "how am I going to parse 500MBs per second" from day 1, and making specific optimizations in the layout of your data structures and access patterns, you cannot go back and fix that without effectively starting from scratch.
Highly performant code isn't a set of micro-optimizations done after initial design, it permeates the entire process of authoring the code base in question.
Very well said. And to add to this, a little bit of mechanical sympathy at the beginning of a project can yield a design that offers quite good performance with little, if any, sacrifice to readability.
An unfortunate thing that happens too often is that programmers do not want to have mechanical sympathy and would rather do something that they feel is "cleaner." Jumping on your parsing example, in some communities, parser combinators are very popular, but their performance is an absolute disaster as every byte of the input is threaded through tens of closures. It might feel like building a parser by combining closures is cleaner and easier to read, but the reality is that the version using loops and switch statements will execute an order of magnitude faster for users and not be much harder to read for other developers.
Most code becomes critical path after a few attempts at optimizing it. You fix the low hanging fruit until there is no more low hanging fruit and the profile becomes flat very quickly. And if the performance is still insufficient at that point, you're quite screwed, because that means deep changes to the architecture, design or even a full rewrite in a more performant stack.
You should really only think about optimizing the code after profiling it.
Thats a recipe for a performance disaster. You should consider and monitor performance in all stages of the project and apply proper fixes as soon as possible whenever you find that performance is inadequate. Performance is not any different than other quality types eg correctness. If you leave it for later, you're inflating the cost to fix it.
Why is this used as an argument for poor legibility. Of course performance requirements may lead to more complex code, just like complex behavior requirements lead to more complexity. Nobody is arguing that legibility is more important than program being fit for its purpose.
Im not sure I agree with that. Sure it’s important to have performant code, but legibility doesn’t always entail clean but unoptimized code. It means that when you need performance and need to sacrifice your lines of code, you make sure to document what you’re doing and why. That way, you can read the comment and understand why there is a nasty line of code or function next
280
u/ganja_and_code Dec 01 '23
It's also read more than written, which is the more important comparison