Performance

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 22/11/2002 at 03:34, xxxxxxxx wrote:

What gives better performance when executing (so which version is faster) :

    
    
    for(i=0;i>xx;i++)
    
    
    
    
    {
    
    
    
    
       if(type==1) {[.....] some stuff to do}
    
    
    
    
       else if(type==2) ....
    
    
    
    
       [...] some more conditions
    
    
    
    
    }

or

    
    
    
    
    if(type==2)
    
    
    
    
      {
    
    
    
    
         for(i=0;i>xx;i++)
    
    
    
    
        {do some stuff}
    
    
    
    
    else if(type==3)
    
    
    
    
    {
    
    
    
    
         for(i=0;i>xx;i++)
    
    
    
    
        {do some other stuff}
    
    
    
    
    }
    
    
    
    
    ?? What do you think.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 22/11/2002 at 07:38, xxxxxxxx wrote:

Definately the second one is faster.

With the first one you are testing 'type' xx times,
but it will always give the same result.

The second approach exploits this, and your loop has no conditionals in it because of this.

Only use the first version if the test is dependent on the iteration number. I'd also recommend replacing the string of 'if else' statements with a single 'switch' e.g.:

If type is dependent on i, use this:-

  
for(int i=0;i<xx;i++){  
switch(type [ i ] ){  
case 1:  
    // Do stuff  
    break;  
case 2:  
    // Do stuff  
    break;  
case 3:  
    // Do stuff  
    break;  
default:  
    // Handle unexpected cases here - i.e. error.  
    break;  
}  
}

If type is _not_ dependent on i, then use this:-

  
switch(type){  
case 1:  
for(int i=0;i<xx;i++){  
    // Do stuff  
}  
break;  
case 2:  
for(int i=0;i<xx;i++){  
    // Do stuff  
}  
break;  
case 3:  
for(int i=0;i<xx;i++){  
    // Do stuff  
}  
break;  
default:  
    // Handle unexpected cases here - i.e. error.  
    break;  
}  
}

You should always add a 'default' handler in there. This doesn't slow your code down (assuming its compiled not interpreted, e.g. C++ rather than coffee), and is a very good habit to get into because you then get a warning when a case happens that you haven't explicitly allowed for.

Another general rule, when nesting loops, make the loop that has the most iterations the inner one.

i.e. use this:-

  
for(i=0;i<10;i++) {  
for(j=0;j<100;j++) {  
    // Do stuff based on i,j...  
}  
}

instead of this:-

  
for(j=0;j<100;j++) {  
for(i=0;i<10;i++) {  
    // Do stuff based on i,j...  
}  
}

P.S. I though the point of the '[' CODE ']' blocks was to
stop the parser messing up code listings?

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 22/11/2002 at 09:01, xxxxxxxx wrote:

Only use the first version if the test is dependent on the iteration number. I'd also recommend replacing the string of 'if else' statements with a single 'switch' e.g.:
-----------------------
switch is only a overview thing but while developement I don´t really care about that. Spaghetti code is my thing.
thanks for the comment on the loop. I will then use the second one.
------------------------
You should always add a 'default' handler in there. This doesn't slow your code down (assuming its compiled not interpreted, e.g. C++ rather than coffee), and is a very good habit to get into because you then get a warning when a case happens that you haven't explicitly allowed for.

------------------------
I only use a default handler when it is possible that anything else could happen. But using a combo menu it is not possible any other case appears so I am saving time.
thx
Samir

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 10/12/2002 at 13:37, xxxxxxxx wrote:

As another time saver if you are in a situation where you are using switch/case blocks with a large number of cases, try a map with the case type as the key and function pointers for the values. It isn't worth it for a small number of cases, but it can be very nice for a large number. A side benefit is that you never again have the problem of forgetting to put in a break.

John