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

I am working on building a search engine. Optimization is what makes the the difference between a user continuing to search or leaving the website. I think It is true for many applications, and unfortunately many of them do not care enough about it. Sometimes it is much cheaper that throwing more hardware at the problem. Unfortunately the latter is easier. To summarize, I'd say you have to optimize whenever you either have to process a LOT of data and/or process it very quickly.

Answer 2

Answer 1:

Many people rightly say "Don't think about performance, optimize later", but remember that they have unit tests. They can rewrite large portions of their codebase without fear of introducing bugs. If you rewrite without any unit tests, you have to manually test everything again, and this time around it's harder because the algorithms are more complex.

You can put off optimization until later but you have to make sure you're prepared for it. If you don't have a workable plan for optimizing later (unit tests, tools to profile your code), then you'd best think about performance now because it will hurt you much more later on.

Answer 2:

Sometimes the simple working solution you first come up with runs in O(n^n) time. If you know you'll have large data sets, then go ahead and optimize it now.

Answer 3:

Some time ago, I got sick of the blemishes in PHP and tried to fix some of them. I wrote a framework which involved a base class that everything had to inherit from. It used method and property overloading, reflection, and just about every other advanced feature to make it work. Then I went ahead and used it in a massive project, using my own framework features instead of the basic language features like isset() and static. The project's code was a little more tidy, but the magic slowed down every method call, and property access by about 50x.

If you're going to try and extend the language itself, you need to think about performance now because you have to re-write everything if you can't optimize it. C has a zero-cost macro system, go for your life. Javascript has no such system, be very careful about writing a new object inheritance system that you want to use everywhere.

Answer 3

It is best to write code and then identify critical areas that would benefit most from optimization.

Sometimes code gets replaced, removed or refactored. Optimizing too much code can be a waste of valuable time.

Answer 4

Performance is not something that can be pasted on at the end of a project.

Answer 5

Generally speaking, obsessing about performance or optimization is the route to much evil in software development. Usually, only about 5% (or less!) of your code has any impact on the performance of the overall system. Your primary goals, first, as a software developer on most projects is getting to correct and reliable functionality and also of course maintainability of the system. Then, once implemented and working correctly, you evaluate performance, find out where the bottlenecks are, and optimize them accordingly to meet your overall goals.

One Caveat: Doing O(n) type evaluations of approaches you take to things are reasonable things to consider in advance as part of the original system design and algorithm selection, etc. just to feel confident the performance will be "in the ball park". But beyond that, most attempts to optimize things in advance of actually measuring where the bottlenecks are will result in optimizing things that don't matter and usually make things less maintainable, harder to understand, etc.

Answer 6

I find my typical pattern for working through a unit of development is:

1. Put together the least version that works through the primary use case from beginning to end. In this step I mainly focus on bare-bones simplicity and a good implementation of whatever patterns apply.

2. Step 2 is to refactor step 1 mainly with an eye toward simplifying. Since I've been doing OOP, the one thing I seem to be able to count on is that this step always presents lots of obvious simplifications and actual reduction in code. It also is the point where the obvious abstractions fall out (which is another simplification.) IMPORTANT NOTE: This has a strong secondary effect of addressing performance, especially when you have done it a few times and you know where the performant antipatterns are.

3. Often, when #2 is done, things are satisfactorily performant, but the tests will confirm this or not; and also point out the (usually very few) locations where optimizations need to be addressed.

Increasingly I see that any time I spend thinking about efficient design in phases 1 and 2 messes up the simplicity, which at that point is primary.