Practical optimization: where to start

[kpreid]

Run your program on a platform slow enough that you

1. care, and
2. can feel where the problems are.

(Something — I assume a Chrome update — caused Cubes to run more slowly. Over fifteen seconds of startup time is just not fun for debugging, so I went looking for problems. Unfortunately, it wasn't anything straightforwardly bad, but the heaviest thing in the profile was the color-picking while constructing the default blockset, so I optimized that and got the startup down to about six seconds. Still slower than it really ought to be.)

Comments

[atheorist.livejournal.com]

There might be a general principle here, something about programmers using their human faculty of empathy with the machine, and that faculty being strained by too great a speed difference.

"playing machine" is a standard training technique.

[(Anonymous)]

I think this is good advice and we often see it applied backwards: the hardware is so fast that we don't need to care about optimizing stuff which translate to inefficiencies and waste (at least in my book).

[kpreid.livejournal.com]

It is entirely reasonable to not care about microoptimization of infrequently executed code.

[(Anonymous)]

Your dead on the money there!! A few years back I was given the task of optimising fetching data for web site that was timing out during certain requests. I was only able to work on the back-end code not the server processing being done to render the pages.
To the dismay of my manager I complete failed as the real performance killer was a pointless bubble sort in front-end that I couldn't do anything about. Given the hard time I had explaining this to result driven management has made me quite nervous about the putting together data back-ends for frankly graduate level coded front-ends.