2010.10.04

The performance dogma

On the past couple years I’ve been noticing that the web community (specially front-end devs) started to become more interested and to care way more about performance, trying to make applications load and execute as fast as possible. I think it was mostly influenced by Steve Souders High Performance Website and Yahoo’s Performance Rules.

Performance is a very important topic, which can directly influence the success/fail of an application, but I do believe that some people are getting things wrong and exaggerating a little bit (including myself)… – Of course everybody wants their applications to run and load as fast as possible but “optimizing” things without need is simply wrong. A common quote about performance explain this:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified” – Donald Knuth

It is not all about performance

It is not just because you read somewhere that a certain technique is faster that you should always apply it. If you’re building a simple application or if a specific task will only happen a few times, there is no point in optimizing it. If the technique/advise doesn’t make the code harder to understand (sometimes it even makes the code cleaner), feel free to use it whenever possible - storing a local reference to a variable that you are going to use multiple times is a good example of what you should always do - but don’t adopt techniques that are going to make the code harder to understand/maintain unless it is going to make a drastic impact on the performance.

It is really important to identify what should and what shouldn’t be optimized, don’t do it just for the sake of doing.

Rules*

  • Don’t waste your time optimizing things that don’t need to be optimized.
  • Don’t sacrifice readability/simplicity unless you really need it.
  • Don’t do it manually if it could be done by a compiler/processor/minifier.
  • Identify what really needs to be optimized.
  • Don’t over-do-it.
  • Make it right before you make it faster.
  • Keep it simple.
  • Don’t try to be too smart.
  • Don’t follow rules “blindly” (including these).

The most common kind of dumb optimization is to do manually things that could be easily done by a compiler/minifier… – If you are naming your methods/variables with a single char just to reduce the file size, you are doing it wrong. Tools like YUI Compressor and Closure Compiler exists exactly for that need, you shouldn’t sacrifice readability if you don’t need it and you shouldn’t be doing this kind of optimization manually, it lends to errors and can make the code really cryptic, think about who is going to maintain the code in the future, including yourself after 1 year without seeing the project…

Another nice quote:

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?” – Brian Kernighan

Scope always matter

As I said before “we should understand the rules to know when to bend them”, if you are building a website with a huge amount of traffic or a tool that makes some crazy heavy operations performance should be on your priority list, but in most of the cases, it doesn’t make that much difference if it takes 10ms or 50ms to perform some task… Don’t take it too serious.

PS: The rules are based on the Program Optimization article on Wikipedia and also based on some things that I’ve read on different sources on the past couple years (that I don’t even remember where I found anymore), some of them I’ve just invented because I think it makes sense and some of them are just common sense.


Comments

I do agree "Make it right before you make it faster". In my younger years I used to try to write the most optimized code from the start, but noticed that I wasn't getting as much done.

Now I do think things through, but I get things working then go back to optimize.

[...] (small subset of mobile webkit browsers), the code structure (yes it is cryptic, yes it has many unnecessary “optimizations”, yes it has some flaws)… I know I’m being a jerk on this paragraph (and maybe with the [...]

[...] thinking that it will slow down your code since you have more functions calls remember about the performance dogma, unless you have a very large loop doing something trivial the extra function calls shouldn’t [...]

Leave a Comment

Please post only comments that will add value to the content of this page. Please read the about page to understand the objective of this blog and the way I think about it. Thanks.

Comments are parsed as Markdown and you can use basic HTML tags (a, blockquote, cite, code, del, em, strong) but some code may be striped if not escaped (specially PHP and HTML tags that aren't on the list). Line and paragraph breaks automatic. Code blocks should be indented with 4 spaces.