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