Inefficient code - Solutions

[Richard Gaskin]

I have nothing to contribute to this thread other than to say thanks.

It's these types of discussions that make this list so valuable, in 
which all of us get a change to explore different algorithms and learn a 
lot along the way.

I've been expecting Alex Tweedly to jump in with some clever use of 
arrays for an order-of-magnitude speed increase, as he's done so many 
times before. :)

Great stuff, guys.  Thanks for this thread.

--
  Richard Gaskin
  Fourth World
  Revolution training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com



Bill Marriott wrote:
> Bernd,
> 
> Thanks for the pointer... I believe I've corrected the error. Here's the key 
> part of the loop with friendly variable names and comments:
> 
>       -- starting with the whole image, check a range of pixels for 
> differences
>       -- keep slicing the range in half until we find a block of unchanged 
> pixels
>       repeat while char currPixel+1 to currPixel+rangeToCheck of ImageA <> \
>              char 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
> 
> My routine will be optimal the fewer changes there are in the image, and the 
> less distributed (more localized) those changes are. It took about 680 ms on 
> my 2.66 GHz Core i7 Vista system, so I took the progress bar out. :) Can 
> anyone improve on it?
> 
> "BNig" <niggemann at uni-wh.de> wrote in message 
> news:24255723.post at talk.nabble.com...
>>
>> I like the ideas to speed up the analysis of differences among 2 images. 
>> My
>> impression is that your approach with div 2 is leading to erroneous 
>> resutls
>> because by dividing by 2 you break the 4 byte blocks of imagedata. 150 div 
>> 2
>> = 75, 75 div 2 = 37, 37 div 2 = 18. You get the idea. You eventually 
>> compare
>> blocks of 4 that belong to 2 pixels. That can be alright but not in all 
>> [...]