   for instead of if
  Hi all,what do you think is the better solution in terms of performance and "space saving" inside binaries between these two?if( level == 5 && points >= values[ 5 * level ] ){ // do something}else if( level == 4 && points >= values[ 4 * level ] ){ // do something}else if( level == 3 && points >= values[ 3 * level ] ){ // do something}for( int i = 5; i >= 3; i-- ) { if( level == i && points >= values ) {<span class="cpp-comment">// do something</span><span class="cpp-keyword">break</span>; }}</pre></div><!–ENDSCRIPT–>
  It won't make a difference.  It will be optimized by the compiler, and would be negligible even if it weren't optimized.   ;  It makes no difference whatsoever in terms of performance or code size -- and if it does, that difference is not worth worrying about.However, it does make a difference in terms of semantics and code style. If "do something" is different each time, perfer the first option. If it's the same each time, the second option is better because you will duplicate less code.   ;Quote:Original post by Clawerwhat do you think is the better solution in terms of performance and "space saving" inside binaries between these two?The loop would be more expensive in terms of execution speed. It will have to execute the loop 3 times. The if statements will fail out at the 'level == x' part.The following would be better, if I remember correctly:switch (level){    case 3:   if (points >= values[3 * level]   {   }   break;    case 4:    ...}I wouldn't worry much about space saving though. The space saved on a C routine is miniscule compared to everything else that's involved in a game. You do need to watch performance, especially in routines that can potentially be called on thousands of objects.   ;  The two methods are not equivalent if you need to do something different each time.If you are doing the same thing in each then why not just:if( level >= 3 && level <= 5 && points >= values[ level * level ] ) { // do something};  Neither will give you any discernable size or performance benefit.Now, here is the real criteria for choosing: if the "//do something" is not the same for all cases, then you must use the first one. If the "//do something" is the same for all cases, then the second is clearly better.In the case of the second one, I would do this instead:if ( level >= 3 && level <= 5 && points >= values[ level * level ] )    {   // do something    } ;Quote:Original post by cdotyIt will have to execute the loop 3 times.Probably not. Compilers are smarter than that. Loop unrolling is one of the oldest optimizations out there, and the early break would probably be inserted too.   ;  well all I can say:Quote:Two or more, use a for!according to E Dijkstra :P   ;  In general: opt for the cleaner (often the more abstract, but not always; avoid going too far the other direction and over-engineering) method of doing things before opting for optimization. If you're finding performance problems, then profile, and then optimize the code that's actually slowing you down. This will avoid premature optimization (in particular, using this abomination — an abomination, IMMO, albeit a clever one — without reason should be punishable by stoning!) which borders on a cardinal sin — by attempting to avoid wasting time, you are very probably wasting time at the most expensive stage (remember, the computer's time is much cheaper than yours).Okay, there are exceptions, but use common sense (and, if you do, then you're probably not optimizing prematurely): don't waste time unnecessarily in the innermost part of a raytracer, but do trust the standard library unless you discover that a specific instance of its use is causing performance problems that you cannot alleviate without introducing uglier code than would be required to simply circumvent the standard library.   ;Quote:Original post by Clawerwhat do you think is the better solution in terms of performance and "space saving"...Premature optimization. Write code to be understood by other programmers. The places you think might be slow or wasteful from a memory perspective may not be, thanks to compiler optimizations. Finish the code, then use a profiler to find the bottlenecks, and only then optimize the code.   