4 ms·

That really seems like the sort of thing that the compiler should be optimizing, the rest just being a case of coding style. It really seems (to me) like saying

by pyre 10y ago

That really seems like the sort of thing that the compiler should be optimizing, the rest just being a case of coding style. It really seems (to me) like saying that `i += 1` isn't as "optimized" as `i++`.

mikeash 10y ago
Yeah, 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. And there is pretty much never an "obvious" place to optimize. Profile first. If you want to call it "obvious" if something takes up 90% of the runtime in the profiler when it shouldn't, then that's acceptable, but don't just look at the code and say "obviously this part is slow."
- krylon 10y ago
  > 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.
  - mikeash 10y ago
    Good point with embedded systems. I must have momentarily forgotten that there are targets beyond PC-like devices.
- dllthomas 10y ago
  > And there is pretty much never an "obvious" place to optimize. Never an obvious place to microoptimize. If you know you're doing a huge amount of unnecessary work, cutting that out can often be obvious.

by pyre 10y ago

mikeash 10y ago

Yeah, 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. And there is pretty much never an "obvious" place to optimize. Profile first. If you want to call it "obvious" if something takes up 90% of the runtime in the profiler when it shouldn't, then that's acceptable, but don't just look at the code and say "obviously this part is slow."

krylon 10y ago
> 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.
- mikeash 10y ago
  Good point with embedded systems. I must have momentarily forgotten that there are targets beyond PC-like devices.
dllthomas 10y ago
> And there is pretty much never an "obvious" place to optimize. Never an obvious place to microoptimize. If you know you're doing a huge amount of unnecessary work, cutting that out can often be obvious.