Inefficient code - Solutions

[Bill Marriott]

Thanks for the encouragement! I have uploaded the test stack to [the new] 
revOnline, with some enhancements to make it easier and more fun to test. 
the tags are:

compare algorithm benchmark bitmap difference
imageData performance pixels

I've also uploaded it here:

http://bill.on-rev.com/linked/Compare2.zip

The full script for my algorithm is:

   --
   --

   put 0 into currPixel
   -- ImageA contains the imageData of image A
   -- ImageB contains the imageData of image B
   -- script assumes both images are the same dimension
   put the length of ImageA into dataLength
   put dataLength into rangeToCheck

   -- check a range of pixels for differences.
   -- the range begins with the full image
   repeat while currPixel < dataLength
      -- keep slicing the range in half until we find unchanged pixels
      repeat while byte currPixel+1 to currPixel+rangeToCheck of ImageA <> \
             byte currPixel+1 to currPixel+rangeToCheck of ImageB
         -- aha, the range we're testing has changes
         if rangeToCheck >= 8 then
            -- eight bytes is at least two pixels...
            -- it's still too big; slice it in half
            put rangeToCheck div 4 div 2 * 4 into rangeToCheck
         else
            -- we're down to a single changed pixel now
            -- record which pixel has changed (offset within the imageData)
            put 1 into bytesChanged[currPixel+1]
            -- move to the next pixel;
            -- assume that changed pixels are near each other
            add 4 to currPixel
         end if
      end repeat
      -- we found one or more unchanged pixels; skip this section of data
      add rangeToCheck to currPixel
      -- and update the range to encompass the remainder of the image
      put dataLength - currPixel into rangeToCheck
   end repeat

   --
   --

"Jerry J" <jhj at jhj.com> wrote in message 
news:F1333741-0799-4E69-B341-EB047C9D928A at jhj.com...
> Bill, I'd like to see your final test stack also. I have another 
> approach, but it doesn't give correct answers yet, at least I don't  think 
> so - at this point I'm no longer sure what the right answers  are. Mine's 
> recursive, and I can't wait to get it running right so we  can see how 
> fast it is (or not).
> --Jerry J