> if your compiler can't optimize the if statement to the same code as the direct return, throw it away and get a new one To be fair, in embedded programming,

> if your compiler can't optimize the if statement to the same code as the direct return, throw it away and get a new one To be fair, in embedded programming, you are sometimes stuck with the compiler a particular vendor hands you. > And there is pretty much never an "obvious" place to optimize. Profile first. Yes, a thousand times yes! ;-) I remember writing a rather convoluted piece of C code a couple of years back that involved stuffing data into a data structure, then looking up data in that data structure. My first thought was "I'm gonna need a hash table", but I used an array and qsort/bsearch, so I could get the rest working; when the rest was working (as in giving me correct results, but at glacial speed), I ran a profiler, fully expecting it to tell me the array/qsort/bsearch-thing was wasting huge amounts of time. I was rather surprised that it amounted to ~2% of the total running time. I've had people tell me before to profile, then optimize the parts that matter, and not to make any assumptions about what parts of my code are going to need optimization. And I did believe the people telling me this, but only at that moment did I understand how right those people were. > "obviously this part is slow." Telling whether a given piece of code is slow (in the sense of "this part could be optimized to run 10x as fast) or not is not too difficult, IMHO. Telling whether it makes up for a significant percentage of the total running time, is. Very hard.