- Micro-optimization will start to make a difference when you process a lot of data or method calls. If you do not already have performance problems, stay away from micro-optimizations.
- Micro-optimizing your code will make it harder to read. Never exchange maintainability for optimizations! The time you loose in maintainability is worth more than the money you could spend on hardware upgrades.
- Premature optimizations is a waste of time. Start micro-optimizing when you've exhausted all other resources.
- There are performance problems and then there are perceived performance by the user. As long as you can maintain a high perceived performance you don't have to micro-optimize your code. This means giving the user constant feedback about what's happening and displaying progress.
20Apr
We don't need micro-optimization!
With the word micro-optimization I'm referring to changing units of code so that it performs better and contributes to the main performance of the application.
Patrick Smacchia wrote a blog post about micro-optimization and that might be the first thing I've heard from him that I can't agree upon. He talks about the importance of micro-optimization and how all software out there could use a fair bit of micro-optimization.
He gives some samples of how you can easily optimize your code base by a few simple tricks. Knowing this reflection guru, he's probably right in all his suggestions, but I would never give in and apply any of them to my code.
Thank you for recommending this blog post to others:
Alive is a performance counter monitor hosted on ASP.NET. You use it to get a dashboard on how your production environment is doing.
3 Comments
Mikael Lundin said
Yes! There are quite different cases and it is hard (impossible?) to apply rules for them all. Working with web applications I know that there are a lot to do in the UI to improve users percieved performance before you start messing with micro-optimzations. If you have a real time application this might become a bit harder to handle.
I talked to the guys in my book circle about this and asked them, "Have you ever encountered a performance problem because of too many nested function calls, using foreach instead of for, or anything like it?" The answer was no, which you might explain with that we're all working with web applications. In our case, performance problems are more often from accessing resources over the network through services. Our performance comes with not making our applications too chatty and in the same time not fill up the memory with cached data, instead of raw CPU performance.
I think I could learn alot from desktop application programming, but I'm a consultant and I work on what pays the bills, sadly so. Not many clients wants destop applications nowadays, because of the accessiblility of web apps. I can't blame them. It's even possible to play Quake in a browser, and with new JavaScript enhancements you won't even need Flash to display 3D anymore.
Alexander Schrab said
Oh, btw... I write network code nowadays. Changed group in the company. And as you say, I tend to encounter more performance problems related to lag etc than actual cpu load bottlenecks...
Alexander Schrab said
We work in quite different sectors of the trade, but the rules of thumb are pretty much the same. I would say micro-optimization is needed in many cases. But you are correct that you should defer doing them until you know you must.
First an overall point when it comes to optimizations: measure measure measure. You think your code uses up a lot of time in a certain function? You think you improved the situation by optimization? Measure or it didn't happen!
Micro-optimization is generally only needed in fucntions that either have very tight real time demands (I have encountered this in a situtation where a plotting function caused frame skips in a network camera), or are called significantly more often than 'normal' code.
If a function is called thousands of times every second (or whatever) causing performance problems, I usually consider two things:
1. Make sure it's not called that often, a lot of the time the reason a function is called so often is a naive or broken high level usage of the function. Perhaps you can take a different approach in solving the problem that does not require that much processing?
2. (Only if 1 is a dead end or not enough) micro-optimize. Make sure it's as fast as it can be. In the case of the camera, I actually ended up rewriting the rather naive implementation in assembler. This is NOT an approach I would recommend to anyone. But in this case it made sense, the computer was a very specific embedded one and the code belonged to a hardware specific driver module, so the assembly code did not introduce any additional hardware dependencies.