Does factorization of code always result in speed increase ? 1

[temp3600]

Hello,

Let's say you have a function like this one :

void f( int n ) {

  ... some code 01 ...

  if( n == 3 ) {
    ... some code Test1a ...
  }
  else {
    ... some code Test1b ...
  }

  ... some code 02 ...

  if( n == 3 ) {
    ... some code Test2a ...
  }
  else {
    ... some code Test2b ...
  }

  ... some code 03 ...

}

To sum up, code where the same test is performed several times in a row. Now consider this function, where the test has been factorized :

void f2(int n) {

  if( n == 3 ) {

    ... some code 01 ...
    ... some code Test1a ...
    ... some code 02 ...
    ... some code Test2a ...
    ... some code 03 ...

  }
  else {

    ... some code 01 ...
    ... some code Test1b ...
    ... some code 02 ...
    ... some code Test2b ...
    ... some code 03 ...

  }

}

My question is : is f2 always faster than f ? Or are there other considerations that i am missing ?

Thanks in advance,
Michael

 

[xwb]

Side effects: does any of the code affect the value of n? If it does then f2 may be faster but it won't give the correct result.

 

[temp3600]

Thank you for your answer.

The code doesn't affect n's value, no.
In f2, the test if(n == 3) is only done once, but some code is duplicated (blocks 01, 02 and 03) as a result. If I understand you correctly, f2 will be faster ?

Michael.

 

[cpjust]

f2 will be faster by saving 1 if statement, but the code will be larger.

 

[temp3600]

Ok, thank you!

Michael

 

[Salem]

> Or are there other considerations that i am missing ?
Well there's the fact that your 2nd effort is now a maintenance nightmare all of it's own.

Some poor schmoe who doesn't realise that code 01 is supposed to be the same in both cases is likely to only change one of them.

Some later schmoe is then left to wonder why they're different all of a sudden.

If n is truly invariant, then any reasonably smart compiler will likely optimise out the 2nd comparison for you anyway, so all you've really done is muck up the code for no good reason.

--

 

[temp3600]

Thank you for your reply.
I'm really interested in speed, and very little in readability and ease of maintenance.
You say that an ok compiler should optimise the second (or more, i just put two in the example) comparison. But will that optimisation reach the speed obtained by factorizing the test (and duplicating most of the code), or will it only come close? That distinction is very important to me!

Michael

 

[Salem]

An optimising compiler will do far more for you than can be simply achieved by copy/pasting your into a different arrangement.

In any event, an extra comparison here or there isn't going to result in any meaningful performance boost. If your "code" does any meaningful work at all, then you're barely going to be able to measure the difference of an extra comparion, let along notice it. Like some small fraction of a second for every day of run-time for example.

http://vision.eng.shu.ac.uk/bala/c/c/optimisation/1/optimization.html

If you manage the first two points, then the compiler will take care of most of the rest. If at the end (I do mean the end, not before) performance isn't up to scratch, then you use a profiler and make careful measured changes to the code. Speculative hacks before then are a waste of time.

The biggest win you'll ever make is making sure you've chosen the best algorithms and data structures for the problem. No amount of clever coding will ever make a bubble sort comparable to even the most trivial implementation of quicksort if you have enough data to sort.

> and duplicating most of the code
Ever consider that bloated code may have a negative impact on your instruction cache?
Some nice loop which previously resided entirely in cache and was running very nicely is now pushed out each iteration and has to be refetched.

Hand-crafted peephole optimisations like the ones you seem keen on are a waste of time and effort, and despite what you think, is never a good reason to sacrifice readability and maintainability.

--

 

[drewdaman]

another thing you shoudl consider is that in your example n==3 is the condition in the if.. having it once or twice doesn't really make much of a difference since such a comparison can be considered to be a constant time operation. but what if you have the result of a O^big power function called in your if condition? you don't wnat to call that more times than necessary. so i would say it is better coding practice to "factor" your code. my point here is that the more complex your "unfactored" comparisons are.. the more they slow your program down.

 

[temp3600]

Thank you for your answers!

Salem, thanks for the link.

Michael