Performance comes first

image

How do you create fast software?

Wrong way

If you are a programmer, you are probably familiar with this quote by Knuth:

Premature optimization is the root of all evil.

Many programmers think this is the normal way to develop products:

image

Some also think that performance is just another feature that can be added later:

image

I think this logic is flawed. If your program is still a prototype and does, for example, 1% (20%, 50%, 90%) of what it is supposed to do, and it is already running slowly, then it will be even slower after you finish it. , is not it so? If you get her to do more, why should he get faster?

If someone says:

We create programs that are correct first, and then productive. We will optimize them after they are implemented.

What this really means is that performance will mostly remain the same, unless these people find simple ways to make the program fast without changing too much of what they have already built.

And I have a problem with that. This is more or less tantamount to the fact that the final performance is left to chance. IF you can manage to find some huge performance bottleneck and if changing it doesn’t affect the architecture, you CAN get some speed up, yes. But no one can guarantee this to you. This is the bet. You will either get some kind of acceleration or not. Basically, you are accepting any performance with little chance of a slight improvement. And would you call it good engineering?

It might seem like history is full of programs that have run faster since release. Just a few examples spring to mind: Chrome is known as the pioneer of many JS speed improvements. The Kotlin and Rust compilers have received a lot of speedups. VS Code / Atom eventually became faster versions of their original Electron prototypes. And I am not saying that it is impossible to speed up programs after graduation. I say these improvements are accidental. They were just lucky. They could never have happened as easily as they did before.

The right way

My takeaway is this: if you want to create a really fast program, pay attention to performance from the beginning. It’s never too early to start measuring and working on performance. Your prototypes should be fast, much faster than the final program.

First, if you start with a fast program, it is much easier to prevent performance degradation than to start with a slow program and hope you find an easy way to speed it up.

Then, if you are really serious about the performance of your final program, every decision must be made with performance in mind. Platform, language, architecture, framework, user interface, business tasks, business model. Can you make them fast? Can we use X language or Y framework, can we make them fast? Can we make this feature fast? If not, what can be used to replace it? How to make the interface fast? How do you make it appear quickly? These decisions are easy to make early on, but not changeable later. For example, JavaScript’s speed has been impressive in recent years, but it still can’t be as fast as C ++ or even Java. If you set yourself the goal of creating a fast language, you would end up creating another language!

Let me put it this way:

“Premature optimization is the root of all evil” is the root of all evil.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *