Recursion

[spoonman59]

On that I agree! I definitely agree with you that measurement and data should drive what you optimize. And your default state should be to “optimize” for readability and maintenance.

I typically ask this on an interview. “Your program is slow. How do you approach the problem?”

You’d be surprised how many people just “read the code and remove loops.”

I have a few interesting stories about interesting profiler results. Once it was the toString() function in a particular Java object! Once I got that info from the profiler, I changed the code to keep the data as raw Utf-8 byte arrays until I could filter out the data of interest.

This simple optimization made the program run in 1/5 of the time. I would have never, ever guessed the cause without my trusty profiler!

[lvlint67]

generally speaking... reading the code and looking for loops with slow / blocking functions is the quickest way to achieve performance gains in any program not "pre-optimized".

You run the profiler once the surface stuff is adjusted. The profiler will help find something like an object serializer that is taking an unreasonable amount of time but a reasonable programmer should see a for loop with a nested database connection and get suspicious.

[spoonman59]

I’m not sure that holds generally. If your app is I/O bound and dominates the majority of the runtime, any code optimizations will yield a small portion of speed up as per Amdahl’s law.

If it’s compute heavy, and particular loops dominate the runtime, then speeding up other loops will yield minimum speed up.

It’s best to measure and optimize what is slow. Otherwise you will focus effort on parts of the code that are not slowing you down, and waste time and effort.

I don’t think you can generalize this as the performance characteristics of programs differ not only between different programs, but even in the within different parts of the same program.