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

Citing Knuth's 'premature optimization .. evil' is a poor argument for writing sloppy and slow code (correct or otherwise).

1. You need metrics to optimize.
2. You need to think about code when you're coding it.
3. You only optimize the subset of code that matters.

If you're writing a simple form to update some details, it's probably not worth optimizing.

If you're writing a google search engine replacement, and you expect to have a lot of traffic, then you figure out a way to make that search as fast as possible.

You only ever need to optimize code that counts, and there's a lot of code in a program for doing one-off things, or events that happen rarely.

---

Given that we satisfy 1, 2 and 3 above:

There's little point waiting until the app is 90% complete before doing any performance testing and optimization. Performance is often an unwritten non-functional requirement. You need to identify and write down what some of these unwritten requirements are and commit to them.

It's also probably too late by 90% complete if you need to make an architectural or other major changes. The more code that has been written, the harder it gets to change things, if only for the fact that there's more code to think about. You need to continually make sure that your app will perform when and where it needs to.

Then again, if you have well written unit tests you should be able to have performance tests as a part of those tests.

My 2 shillings at least.

Answer 2

You should optimize for performance after you've built your application and only if you have proof where your bottlenecks are. (E.g. by profiling) Maybe you find out that it's not necessary to optimise, especially because the compiler is usually much better at it than you are.

Answer 3

Don't think about performance until after you've got it working correctly. If it works correctly, and it doesn't have any user noticable performance problems, don't optimize.

If it works correctly and it has significant and noticable delays, don't optimize. Profile instead. Most of an application's time is going to be spent in a single "hot" loop, and which loop it is is seldom intuitive. You need real measurements and science to tell you what's happening. Once you have your profile data, your optimization task should progress from big to small:

1. Architecture optimizations. Is the overall structure of the application the source of the inneficiency?

2. Algorithm optimizations: Are you using the right data structures? Are you accessing them in the right way? Is your application spend most of its time writing, or most of its time reading? Optimize for the answer to that question.

3. Last resort. Microoptimization. Streamlining the hot loops, or unrolling some loops. Duff's Device. Don't optimize at this level until you've determined that you can make no further improvements to the other two levels, and you still haven't met your performance goals. This level of optimization has a high likelyhood of breaking shit, and making your application more difficult to grow, more brittle, so don't do it unless you really really have to.

Again I will emphasize, don't waste your time on optimizing just any random bit of code that looks inefficient. Optimization time is a significant investment. You should have evidence to back you up before you gamble your time on a loser.

Answer 4

Like other people have said, optimizing before you know the problems is a waste of time. I recently worked on some code that had a lot of optimization, and most of my time was spent removing the optimization! The problem was that it made adding critical functionality impossible.

Another example...in my previous job I worked in Data Processing, writing scripts around executable programs. If I started a program at 5 PM at night, and it finished by 8 AM the next morning, it was fast enough. Of course, in the case of emergency it was much better for it to take one hour instead of ten, and faster code made my job easier, but as long as it ran correctly 30 minutes was equivalent to 16 hours.

It depends totally on your project...and should be considered in your project requirements.

Remember also that making a program more efficient takes longer...you're trading off speed of development for speed of execution.

Answer 5

When it does?

No, seriously. There are some applications that will never have enough users to warrant more than the basic indexes and key relationships in the database. They won't require tuning inner loops of the code. Workgroup size applications, for example.

As things scale, so does the demand for optimized paths, both in code, data access and communication. If you are working on limited hardware (embedded systems) you care a lot about performance. But there are many, many applications that will never see enough users to make the systems resources even notice you are there.

In those cases, all that extra work is wasted money and effort. In some cases your specification makes it clear you need that extra effort. In some cases it makes it clear you never will.

Answer 6

I had a phase where I was absolutly paranoid about performance. I spent so much time trying to improve performance that my code never actually progressed. Don't get into that habit :-)

Code, THEN optimise, not both at the same time.