Inefficient code - Solutions

Jerry J jhj at jhj.com
Tue Jun 30 15:25:54 EDT 2009


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

On Jun 30, 2009, at 12:08 PM, Generic Email wrote:

> Bill, this is phenomenal. I added the progress bar BECAUSE it was  
> taking so long.
>
> Your code is much faster. I tried adding the revision below to you  
> stack, but I keep botching something and it is recognizing 0  
> changes. Once you are happy with it, I think it would be great to  
> see it in Revolution Online. Until then, could you post your final?
>
> Thanks
>
> Bert
>
> On Jun 29, 2009, at 2:30 PM, 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
>>> [...]
>>
>>
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the use-livecode mailing list