Linked by Thom Holwerda on Fri 13th Feb 2009 16:19 UTC, submitted by ShlomiFish
General Development There's a new essay called "Optimizing Code for Speed" available on Shlomi Fish's site. It covers the motivation, methods and terminology of optimizing code, and provides many links and examples to illustrate this important subject.
Permalink for comment 348746
To read all comments associated with this story, please click here.
Good article but beware...
by leos on Fri 13th Feb 2009 19:35 UTC
leos
Member since:
2005-09-21

Good article, but overall I don't think they emphasized the point enough that you shouldn't start optimizing if you can help it. While the author does touch on that, they don't emphasize it enough. After all:

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson


For example, quotes from the article such as this worry me:
As a result, eliminating a dependency on GLib's data structures may improve the performance of the program.


If your program is built on glib, USE GLIB FUNCTIONS. If you're using Qt, USE QT FUNCTIONS. If that's not fast enough (and it is for 99% of cases) then investigate a more specialized library, but avoid at all costs writing your own data structures (unless you have a very unusual requirement and have gotten at least 2 other expert opinions on the matter).

I understand the lure of optimization. It's tons of fun to profile something and save some cycles here and there, and I always scroll right to the optimization section of the KDE commit digest, but I also understand that it is often just that, "fun". I'm not against making stuff faster, but you really have to get your facts straight first.

I think the take home message is "think before you optimize". I recall a post to a message board complaining that painting an image in Qt was taking half a second. At least 3 different people immediately replied that the original poster should just use OpenGL and it would be faster, without even considering that there must be something weird going on for painting to be that slow. Well I asked for his code, and it turned out he was reading each pixel from the image and painting it to the screen (so there were hundreds of thousands of function calls for every paint event). Of course a change to paintImage() solved everything.

Edited 2009-02-13 19:39 UTC

Reply Score: 5