Inefficient code - Solutions

[Bill Marriott]

Bernd,

Actually in my testing on my machines, over about 20 tests, your change ends 
up being slightly slower by about 1%, depending on the images :) I think 
it's because you downshift into checking pixel-by-pixel again, and there 
would have to be fewer checks that way then if the check range were larger. 
It's interesting how the timed duration can change from one execution to the 
next.

> [I] added a forward search when the
> comparison is not unequal, figuring that going forward yields faster
> results. Well it kind of does, if one thinks 5 to 10 milliseconds are an
> improvement...

>   put 4 into tIncrement
[...]
>      -- we found one or more unchanged pixels; skip this section of data
>      add rangeToCheck to currPixel
>
>      -- this is added to Bill's original code
>      -- assume there are more unchanged pixels and go forwards
>      repeat while char currPixel+1 to currPixel+tIncrement of ImageA = \
>             char currPixel+1 to currPixel+tIncrement of ImageB
>         add tIncrement to currPixel
>         add tIncrement to tIncrement
>         if tIncrement > dataLength then exit repeat
>      end repeat
>      -- end addition to Bill's code
>
>      -- and update the range to encompass the remainder of the image
>      put dataLength - currPixel into rangeToCheck