Comment by davedx
7 hours ago
"today, performance is mostly about architectural choices, and it has to be given consideration right from the start"
This doesn't make sense. Why is performance (via architectural choices) more important today than then?
You can build a snappy app today by using boring technology and following some sensible best practices. You have to work pretty hard to need PREMATURE OPTIMIZATION on a project -- note the premature there
Sorry but you are just wrong. There are very few coding changes that you can make to fix performance issues that users will notice. Almost all the optimization changes they might notice are architectural changes. This is because CPU bound code is very rare and if you have that case you are probably doing something wrong architecturally. Code being memory bound is 99.999% of the time what is happening. And optimizations to memory bound code are almost always architectural too. Any coding changes, even to a huge platform's codebase can probably be found and fixed in a couple of hours. Anything non-architectural that takes longer than that, is about as likely to create noticeable improvement as you winning the big jackpot in a lottery.
The big thing that changed is that almost all software performance today is bandwidth-bound at the limit. Not computation-bound. This transition was first noticed in supercomputing around 25 years ago.
Optimization of bandwidth-bound code is almost purely architectural in nature. Most of our software best practices date from a time when everything was computation-bound such that architecture could be ignored with few bad effects.
I agree. But I have to say, when defining the architecture, there are things known that will be terrible bottlenecks later. They should be avoided. Just as the previous comment, about defining proper indices in a database. Optimization means making something that is already “good” and correct better. There is no excuse to make a half ass, bug ridden shitty software, under the excuse “optimization is for later” that is technical debt generation: 2 very different things.
> You can build a snappy app today by using boring technology and following some sensible best practices.
If you are building something with similar practical constraints for the Nth time this is definitely true.
You are inheriting “architecture” from your own memory and/or tools/dependencies that are already well fit to the problem area. The architectural performance/model problem already got a lot of thought.
Lots of problems are like that.
But if you are solving a problem where existing tools do a poor job, you better be thinking about performance with any new architecture.
In the 1970s computer systems spanned fewer orders of magnitude. Operations generally took somewhere between maybe 1 and 10^8 CPU cycles. Today, the range is closer to 10^-1 to 10^13.
> Why is performance (via architectural choices) more important today than then?
There were fewer available layers of abstraction.
Whether you wrote in ASM, C, or Pascal, there was a lot less variance than writing in Rust, JavaScript, Python.