Inefficient code - Solutions

[BNig]

Bill,

why I tried to do a forward check for equality is that I thought it would be
faster, because you always start at the end and come down to find the pixels
that are not equal/equal.
I wanted to go forward until there is inequality . And then proceed. From my
feeling this could lead to fewer operations. Of course depending on the
images.
So I turned your approach around: 
fits into your stack.
core algorithm:
----------------------
 set the cursor to watch
   put 0 into numCalcs
   put the milliseconds into t
   -- begin timing
   put 0 into currPixel
   put the length of ImageA into dataLength
   put 4 into rangeToCheck
   
   repeat while currPixel < dataLength
      -- check forward for equality of chunks of the two images
      repeat while char currPixel+1 to currPixel+rangeToCheck of ImageA = \
             char currPixel+1 to currPixel+rangeToCheck of ImageB
         
         -- was equal so double the range to check
         add rangeToCheck to rangeToCheck
         if rangeToCheck > dataLength then exit repeat
         
      end repeat
      -- we found one changed pixel, rangeToCheck = 4
      if rangeToCheck  = 4 then
         put 1 into bytesChanged[currPixel+1]
         add 4 to currPixel
      else
         -- since equality failed the last valid rangeToCheck value was
rangeToCheck div 2
         add rangeToCheck div 2 to currPixel
         -- start anew with 4 Bytes
         subtract rangeToCheck - 4 from rangeToCheck
      end if
   end repeat
   
   -- end timing
   put the milliseconds - t into theDuration
---------------------------

since my last indications on performance were a little off, I leave it up to
you to determine that. :)
(more an academic exercise)

regards
Bernd
-- 
View this message in context: http://www.nabble.com/Inefficient-code-tp24226458p24288750.html
Sent from the Revolution - User mailing list archive at Nabble.com.