Code-Tuning Strategies

[[deleted user]]

This is one of the best discussions of performance tuning that I have seen. I, too, have experienced the pendulum swing of the importance of this task. At first, it was an essential skill. As processor speed accelerated and compiler technology advanced, it became less important. Now, with mobile devices, it is the limelight once again.

The biggest point, in my view, is that most major performance problems can't be fixed with a little code tweaking, but typically require a major rethinking of algorithms and data structures. Also, it is truly difficult to identify the performance bottlenecks without measuring them, and this is best done after the code is functionally complete.

[Erik]

I liked this chapter. I was suprised to read the "it's ok to optimize after the fact". It makes sense that optimizing code that seldomly gets used it wasteful.

I very much agree with the 80/20 rule being applied to optimization. Updating a function or two is almost always enough. Sometimes making an i/o cache intelligent is a good type of optimization too.

It's been about 10 years since I've tried to "beat the compiler" with optimizing to assembly for mobile phones. I'd be suprised if that works anymore for any popular platform.

[Aleksander]

I’ve never done any optimization work using a profiler, though it sounds interesting and provided data is impressive. I also liked the examples based on author’s own experience. My favorite section is Measurement. At work optimization topic comes up only when something is really slows down the whole system, which is rarely relates to the part of the project I’m responsible for. I try to keep my code readable and isolate unreadable but efficient algorithms inside specific functions. After reading Measurement, it would be interesting to use a profiler and see if there is any benefit of using “optimized” functions…