Linked by Thom Holwerda on Fri 13th Feb 2009 16:19 UTC, submitted by ShlomiFish
Permalink for comment 348746
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/24/13 17:26 UTC
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
More Features »
Sponsored Links



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:
For example, quotes from the article such as this worry me:
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