Do I always have to think about performance?

Question

I come from a DBA world and performance has always been an obsession. I am turning to development and I always think about performance, constantly, all the time.

Reading

Answer 1

The Knuth quote ("We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil") probably applies.

When you drive your car, do you constantly and consciously check how close your car is to the curb? If you have enough experience driving a car you learn to know where its edges are and roughly how to drive and park it without hitting something close by.

The analogous kind of intuition/experience for programming performance is important to gain through trial/error and questions, but you shouldn't have to spend your time constantly double-checking yourself.

Answer 2

I think there are two contradictory proverbs that are relevant here.

1: Premature optimization is the root of all evil.

2: Look before you leap.

In my personal experience, it has been the case that when code is first written, the probability of finding the magic 3% of the code that is using 90% of the resources is very easy to find. This is where the first proverb is relevant, and seems to produce great results. As the code base matures however, it seems to be that instead of 3% using 90% of the resources, you suddenly have 50% using 90% of the resources. If you imagine the analogy of a water pipe, instead of a few big leaks, you now have the problem of multiple small leaks, all over the place. This gives the overall application slow performance, even if its hard to pin down to any one individual function.

This is where proverb 2 seems relevant. Don't rely on the first proverb to not do any performance planning, have an overall plan, even if it an evolving one. Try work out some acceptable performance metrics and time your program. Consider the later performance implications of design choices. As an example, one might plan to use a tuple store rather than a database in advance if all that is needed is a tuple store. Starting with an SQL database and then changing to a tuple store later is quite difficult.

Above all, do try to optimize where its easy and make notes about cases where optimization is possible. If you don't, as time goes on, programs tend to suffer the death of a thousand cuts, as the effect of functions that are 5-20% slower than they need to be add up and indeed multiply.

Answer 3

For me, when i am working with image manipulation, multiple large sql queries or loops that pass the 100k mark, i think about optimization. Otherwise i don't, unless i see its slow when its working.

Answer 4

You want to think about performance regarding a particular issue as often as you might have to deal with performance issues on each issue one day.

Meaning -- if it isn't going to get a ton of use, worry accordingly. Don't be incredibly lazy or inefficient, and don't over obsess in getting algorithmic nirvana each time. It's often best to code simplest and make it faster/optimized as needs arise. In the meantime simple code can be worked on by any developer and it's something worth considering.

If you see it's importance increasing, now you know to think about it some more as it will come to bite you in the rear.

As developers we have an issue of wanting a perfect v1.0. A working v1.0 is soemthing that works, not perfect for every situation the future may ever bring.

A good example for me was when I started playing with databases many years ago. I didn't know what additional indexes were or the great performance boosts they give when queries unimaginably slow down.

We can't predict every problem. I try to do good design, and let problems fight for my attention.

Hope something was of use.

Answer 5

It usually comes down to the requirements. In some cases you have very strict non functional requirements for response times, etc. In those cases, you should be extra effort to tweak your code, procedures, etc.

But as a rule of thumb (IMHO), you should build your code based on best practices around reliability and maintenability and then have a specific round of tests around performance. This way, you will know that you will be tweaking only the bits of code that are actually impacting the performance.

Answer 6

Nope, if you're going to be thinking of something then think about delivering value to your employer/client and customers. Think about what counts for them.

That said, performance is important but it can lead to ruin.

Dawn of War 2 was released in February with a game breaking bug that destroys multi-player. The issue? Population cap. When a squad is re-enforced the last unit takes up double the cap due to a coding error. This means you can be in a situation where you have a very small army and when you try to create a new unit the game tells you that you have too many units on the field. Most frustrating.

Why should this be an issue? How can this be an issue that only occurs with re-enforcement? If it was an issue with just buying the unit then surely it would have been discovered in testing!

Well my guess is that it is due to premature optimisation. The developer didn't want to foreach all the units when you click the "buy unit" button and instead made pop-cap like a bank so when a unit is created it takes cap out of the bank and when it dies pop cap is put back into the bank. Sure that's more performant, but one little mistake throws the whole bank out of step.

So what's worse, a small perf hit when you press that "buy unit" button or a lot of flaming in the Dow2 forum, angry customers and MS dragging their heels with certifying the fix meaning that it isn't fixed yet?

In a lot of cases its better off marking a

// todo: performance could be better
// try doing xyz if we need to improve it

because the performant version takes more time and adds a maintenance cost to the code.

The performance you should be worrying about is delivering a solution to your client that is satisfactory and fulfills their need. The speed of getting to the release date is usually more important.

There are scenarios where general performance is important such as embedded systems but this should be known as a restriction up front and is a special context you should be aware of before you hit the code.