compileIt for revolution?

[Alex Tweedly]

Sorry - this was sent yesterday, and has been held up by problems 
contacting RunRev site - trying again ....

>Date: Wed, 29 Jun 2005 22:38:50 +0100
>From: Alex Tweedly <alex at tweedly.net>
>Subject: Re: compileIt for revolution?
>Jon wrote:
>
>  
>
>>Derek:
>>
>>Let's put it differently.  My real interest is in seeing how to 
>>optimize Rev code to access arrays in general, and image data in 
>>specific, as rapidly as possible.
>>    
>>
>
>I trust you've already read all the "tricks to optimize code" mentioned 
>on the list last week (in particular, the ones from Ken's sonsothunder site)
>http://www.sonsothunder.com/index2.htm?http://www.sonsothunder.com/devres/revolution/revolution.htm
>
>Accessing arrays in Rev is slow-ish because they are associative. They 
>are quick for assoc arrays, but it's still a look-up.
>
>Access to numbered chunks (e.g. line 3, item K, ...) is dependent on the 
>number being accessed - because it requires a pass through the variable 
>to count chunks. The one big exception to this is character access - 
>char N is a direct lookup (offset N from the start).  So if you can 
>access "char N of variable" that is much faster ....
>
>So the big message for image processing is - don't access it as an 
>array, access it as chars in a variable.
>
>Your Brightness code took (for me, for one med size photo)
> 8.5 seconds to convert from tImagedata into your arrays
> another 8 seconds to ComputeHistogram
>
>By leaving it as tImageData, I could save the conversion time of 8.5 
>seconds.
>*and* I could reduce the ComputeHistogram time from 8 seconds to around 
>2 seconds, by changing
>
>  
>
>>  repeat with r = 1 to imH
>>    repeat with c = 1 to imW
>>      put Brightness(c, r) into i
>>      add 1 to histo[i]
>>    end repeat
>>  end repeat  
>>
>>    
>>
>to (NB uses the fact that the "spare" byte is always zero)
>
>  
>
>>   repeat for each char c in lImageData
>>     add chartonum(c) to temp
>>     add 1 to count
>>     if count = 4 then
>>         add 1 to histo[temp]
>>     end if
>>   put 0 into temp
>>   put 0 into count
>>   end repeat 
>>    
>>
>
>
>
>I realized that this still requires an access to an array for each 
>increment to "histo". It would be great if there were a "direct access" 
>integer variable type, but there isn't. However, if you are desperate 
>enough to save time, you can use "char N" accesss to a temp variable, 
>and then you can convert that into array accesses: thus the section
>
>  
>
>>    if count = 4 then
>>        add 1 to histo[temp]
>>      end if
>>    
>>
>
>becomes
>
>  
>
>>if count = 4 then
>>      add 1 to temp   -- because 1:256, not 0:255
>>      put numtochar(chartonum(char temp of mytemp) + 1) into char temp 
>>of mytemp
>>      if chartonum(char temp of mytemp) = 255 then
>>        add 255 to histo[temp-1]
>>        put czero into char temp of mytemp
>>      end if
>>      put 0 into temp
>>      put 0 into count
>>    end if
>>    
>>
>
>remembering that at the end you need to roll them up
>
>  
>
>>repeat with i = 1 to maxHist+1
>>    add chartonum(char i of mytemp) to histo[i-1]
>>  end repeat
>>    
>>
>
>This rather extreme measure reduces the time to 1.2 seconds.
>
>So in some ways that's a good saving 8 seconds to 1.2 - but in other 
>ways it shows that it's probably flogging a dying horse.
>
>Although I didn't complete it, I believe this technique applied 
>throughout your example would reduce the overall time for this photo of 
>mine from around 55 seconds to 10 or 12 seconds.But the cost is some 
>ugly, barely maintainable code, and it's still beyond the stretch of 
>what a user would be willing to wait for a simple transformation to be done.
>
>
>  
>


-- 
Alex Tweedly       http://www.tweedly.net

-------------- next part --------------
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.2/29 - Release Date: 27/06/2005