   Pop Quiz!! What's faster??
  //Common Valuesint bigNumber = 99999999;float value = -1;float value2 = 0.01;// OPTION A:for(int i = 0; i < bigNumber; ++i) { value -= value2;}// OR OPTION B:for(int i = 0; i < bigNumber; ++i) { if(value > 0) value -= value2;}I know this is really specific, etc.. but just out of curiosity which would be faster? Subtraction? Or the if statement?Thx,Ben.   
  Umm your if statement will always return false cause -1 is always less then 0...Also I don't see what the if statement really does anything different from option A   ;  There's no way to tell how fast your actual code is going to run. Figuring out the performance of a piece of code does not simply involve reading the "slow" bits and deciding which alternative is "faster."For gathering data about our programs and their performance, we use profilers. A profiler will tell you exactly how fast the code is in a real world situation, versus us sitting around and speculating and probably being wrong.There are literally dozens of factors that could affect the performance of your real code, ranging from compiler optimizations to CPU instruction reordering to cache coherency and so on. What that snippet looks like in isolation has basically no bearing whatsoever on the performance of your actual code.So, in summary: use a profiler, and you'll find out which one is faster [smile]   ;  With a good compiler, option B will evaluate to zero CPU cycles, and option A will evaluate to a single floating point move (value = -1000000.99).But as ApochPiQ said; profile and see.   ;  I'm aware of that OPTION B will always be false in this example. I was just wondering which option would process faster, regardless.If you must know the context.. I have a chat log where the lines of chat fade after about 10 seconds. In this example, value would be the chat line's lifetime, and value2 would be the time between frames (delta time). So in reality value will actually start at 10, not -1. But for this example I made it -1 for simplicities sake.Basically the question is: if I'm going to be subtracting the delta time from a float every frame.. and don't care what the value is once it's below 0.. is it faster to check if it's above 0? Or to simply subtract the value anyway.I understand that how the code is compiled makes a big difference. I guess I was hoping that in theory.. on average.. one option would be faster than the other. For example.. Surely a + a is faster than a*a, which is faster than pow(a,a), yes?Or with IF statements.. comparing boolean values is faster than comparing float values? Correct me if I'm wrong here, of course.. but is comparing 2 float values on average faster or slower than subtracting 1 float from another?   ;  Another question is whether it matters at all where you are using it. What's the point of making the text fade a microsecond faster, if the program is going to sit and wait for a timer event anyway? Or, do you think the math is going to take a significant proportion of time compared to actually rendering the result?Does the program *feel* slow or are you optimizing in advance something that you haven't written yet?   ;  Strictly speaking, introducing a branch of any kind (i.e. an if, a loop, etc.) will risk being slower than the code without a branch. This is not a guarantee that it will be slower, but if the branch is hard for the CPU to predict, you will incur a penalty. Technically there is some overhead to the branch regardless.However, this overhead is so minuscule that you would have to literally go to extra effort to even see a slowdown between one version or the other. Frankly this is pretty much a terrible case to focus on if you're worried about performance, because it's so trivial the odds of it causing performance problems are next to nil.   ;  CPUs generally do number comparison by substracting and checking if the result is zero (or positive or negative, if you do < or > comparison).  So it's the same.And this is meaningless anyway: profile.  If you must, look at the generated assembly.  Also, CPUs are not that starightforward as you may think they are; they do tons of black magic under the hood.  And there's tons of various CPUs -- maybe, if you profile that option A is faster on your CPU, it will actually be slower on anyone else's.Optimise your algorithms, not tiny things like this.   ;  Yup, this is purely out of curiosity. This will only happen 60 times a second for each chat log, so in this case there will be no visible slowdown at all. I'm more asking just to get a better understanding of how it all works.. and also so next time I need to do something like this (but bigger), if one option IS on average faster than the other.. I'll just code it that way instead of the other. After all, it's not like it requires any extra effort, so might as well do the faster version.If seems to me.. that although in this case it doesn't matter.. in GENERAL.. in theory.. option A will be faster. Because OPTION B has to do the subtraction anyway.. and also introduces a new branch of logic.However.. as has been mentioned.. the CPU isn't quite that straightforward anyway, so in some situations it could be reverse.This sound about right?Thx,Ben.   ;  I'm not entirely sure how often such micro-changes have a large impact (seeing that the compiler may be doing god knows what with the code). Usually, when there's a real bottleneck more radical changes are more useful, e.g replacing a dumb O(n) algorithm with a smarter O(log n) algorithm etc. If there are such optimization possibilities, you can optimize code to do a dumb thing as fast as possible all you want, but the gains will not be very large.   