Comments on: Wasting time on micro-optimizations http://outofcheese.org/2004/03/07/wasting-time-on-micro-optimizations/ Redo from start.... Wed, 7 Jan 2009 10:16:35 +0000 http://wordpress.org/?v=2.5.1 By: Anonymous & Coward http://outofcheese.org/2004/03/07/wasting-time-on-micro-optimizations/#comment-394 Anonymous & Coward Tue, 16 Mar 2004 11:59:47 +0000 http://outofcheese.org/?p=581#comment-394 Even if the code was stated to have an undefined behavior, it's a stupid question. Nobody codes like that since 1970 and I agree it's like asking what value is in PC when you finish a blur filter on a tiff picture in Photoshop 3.0.1. A wonderful article was published in an issue of Develop (from Bob3 Johnson : Killing the Time Killers IIRC) explaining why this sort of code is deeply stupid. The FIXME thing is interesting as I'm using a similar method. The issue I see with this is that sometimes I don't remember what fix I needed to make :) Even if the code was stated to have an undefined behavior, it’s a stupid question. Nobody codes like that since 1970 and I agree it’s like asking what value is in PC when you finish a blur filter on a tiff picture in Photoshop 3.0.1.

A wonderful article was published in an issue of Develop (from Bob3 Johnson : Killing the Time Killers IIRC) explaining why this sort of code is deeply stupid.

The FIXME thing is interesting as I’m using a similar method. The issue I see with this is that sometimes I don’t remember what fix I needed to make :)

]]> By: Buggin' My Life Away http://outofcheese.org/2004/03/07/wasting-time-on-micro-optimizations/#comment-396 Buggin' My Life Away Mon, 15 Mar 2004 17:58:22 +0000 http://outofcheese.org/?p=581#comment-396 <strong>Coding Tricks and Interviewing</strong> Coding Tricks and Interviewing

]]> By: Buggin' My Life Away http://outofcheese.org/2004/03/07/wasting-time-on-micro-optimizations/#comment-395 Buggin' My Life Away Mon, 15 Mar 2004 17:57:30 +0000 http://outofcheese.org/?p=581#comment-395 <strong>Coding Tricks and Interviewing</strong> Coding Tricks and Interviewing

]]> By: Eric http://outofcheese.org/2004/03/07/wasting-time-on-micro-optimizations/#comment-393 Eric Mon, 15 Mar 2004 01:06:56 +0000 http://outofcheese.org/?p=581#comment-393 It'd be a valid interview question if it was along the lines of "This is undefined behavior in C. Why, and what does that mean?" Simply giving them the line of code and asking what it does isn't fair, though. I can't reasonably expect anyone to understand exactly what's undefined in every programming language. It's like copying code from an obfuscated C contest and asking an interview candidate what it's doing. They're not going to write code like that (well, hopefully not, and other questions will show that) and we shouldn't have anyone around who'd write code like that. If they're never going to have to deal with anything like it, it doesn't really matter if they don't know exactly why it works (or doesn't work) in the way that it does. It’d be a valid interview question if it was along the lines of “This is undefined behavior in C. Why, and what does that mean?” Simply giving them the line of code and asking what it does isn’t fair, though. I can’t reasonably expect anyone to understand exactly what’s undefined in every programming language. It’s like copying code from an obfuscated C contest and asking an interview candidate what it’s doing. They’re not going to write code like that (well, hopefully not, and other questions will show that) and we shouldn’t have anyone around who’d write code like that. If they’re never going to have to deal with anything like it, it doesn’t really matter if they don’t know exactly why it works (or doesn’t work) in the way that it does.

]]> By: Brooks Moses http://outofcheese.org/2004/03/07/wasting-time-on-micro-optimizations/#comment-392 Brooks Moses Sun, 14 Mar 2004 03:01:09 +0000 http://outofcheese.org/?p=581#comment-392 Huh. It seems like a perfectly valid interview question to me -- one of a sort that I'd be likely to ask, were I interviewing. It seems a valuable filter for the people who have a proper understanding of the meaning of "operation undefined" (and an ability to recognize when it applies), which is a quality worth filtering for in people one's hiring to do programming. Huh. It seems like a perfectly valid interview question to me — one of a sort that I’d be likely to ask, were I interviewing. It seems a valuable filter for the people who have a proper understanding of the meaning of “operation undefined” (and an ability to recognize when it applies), which is a quality worth filtering for in people one’s hiring to do programming.

]]> By: Alexei Kosut http://outofcheese.org/2004/03/07/wasting-time-on-micro-optimizations/#comment-391 Alexei Kosut Tue, 09 Mar 2004 02:04:30 +0000 http://outofcheese.org/?p=581#comment-391 Yep. C++ is the one area where ++i vs. i++ matters, since if those operators are overloaded, the compiler can't substitute operator++() for operator++(int), even though that's probably what you meant. With the STL, ++ is a common operator on objects, although most STL implementations try hard not to make an incidental iterator copy here and there cost too much. And, of course, in most cases iterator copy cost is not something you need to waste your time optimizing. I think it's a shame that the C++ language doesn't define some semantic requirements for overloaded operators that would allow the compiler to do these sorts of optimizations, but I guess that wouldn't exactly make C++ any simpler to understand. Yep. C++ is the one area where ++i vs. i++ matters, since if those operators are overloaded, the compiler can’t substitute operator++() for operator++(int), even though that’s probably what you meant. With the STL, ++ is a common operator on objects, although most STL implementations try hard not to make an incidental iterator copy here and there cost too much. And, of course, in most cases iterator copy cost is not something you need to waste your time optimizing.

I think it’s a shame that the C++ language doesn’t define some semantic requirements for overloaded operators that would allow the compiler to do these sorts of optimizations, but I guess that wouldn’t exactly make C++ any simpler to understand.

]]> By: louis http://outofcheese.org/2004/03/07/wasting-time-on-micro-optimizations/#comment-390 louis Mon, 08 Mar 2004 01:27:45 +0000 http://outofcheese.org/?p=581#comment-390 When I am writing code I often am trying to get the thing running at all, as opposed to totally correctly. So I end up sprinkling a ton of //FIXME's all over my code, which need to be taken care of before it can be committed, but are things I can hardcode or ignore while I am doing the initial bring up. While I am at it, I also tend to leave //PERF's next to anywhere I think that there is a win to be had but that I don't want to deal with because it is either more complex, or I want to see profiling data first. Its a quick hint, and it lets me express my first instincts on optimizations without actually impairing my code readability or complicating my initial debugging. As for ++i... I need to disagree with you a little on this one. Not about the optimization thing, your right, people who believe the compiler can't transform a post-increment to a pre-increment when it needs to should not be doing that sort of optimization. The thing is that i++ is a more complicated semantic, copy, then increment original. ++I is simply an increment. In general if I have two interfaces that allow me to achieve the same result, but one may have an incidental side-effect that in a particular context I don't need then I use the simpler one, because it means that I am less likely to spend a bunch of time debugging some stupid bug in a copy constructor that I did not even need or want called. This is especially irritating because it is the sort of bug that may go away or come back when you change optimization levels. This is some ways only really an issue because people can overload operators with things that are not semantically compatible with their general arithmetic meaning. I suppose what I am saying is the fewer external functions you invoke the simpler things are to debug. In any event, I find that the best thing to do generally is to follow the style of the code I am modifying, and to only changes things when there is heavy refactoring going on anyway, because adding something that is "stylistically better" just adds one more inconsistency to the code base. When I am writing code I often am trying to get the thing running at all, as opposed to totally correctly. So I end up sprinkling a ton of //FIXME’s all over my code, which need to be taken care of before it can be committed, but are things I can hardcode or ignore while I am doing the initial bring up. While I am at it, I also tend to leave //PERF’s next to anywhere I think that there is a win to be had but that I don’t want to deal with because it is either more complex, or I want to see profiling data first. Its a quick hint, and it lets me express my first instincts on optimizations without actually impairing my code readability or complicating my initial debugging.

As for ++i… I need to disagree with you a little on this one. Not about the optimization thing, your right, people who believe the compiler can’t transform a post-increment to a pre-increment when it needs to should not be doing that sort of optimization. The thing is that i++ is a more complicated semantic, copy, then increment original. ++I is simply an increment. In general if I have two interfaces that allow me to achieve the same result, but one may have an incidental side-effect that in a particular context I don’t need then I use the simpler one, because it means that I am less likely to spend a bunch of time debugging some stupid bug in a copy constructor that I did not even need or want called. This is especially irritating because it is the sort of bug that may go away or come back when you change optimization levels. This is some ways only really an issue because people can overload operators with things that are not semantically compatible with their general arithmetic meaning. I suppose what I am saying is the fewer external functions you invoke the simpler things are to debug.

In any event, I find that the best thing to do generally is to follow the style of the code I am modifying, and to only changes things when there is heavy refactoring going on anyway, because adding something that is “stylistically better” just adds one more inconsistency to the code base.

]]>