Same-size chunk replacements (was RunRev vs RealBasic)

[Richard Gaskin]

Dar Scott wrote:
> 
> On Jan 19, 2005, at 11:33 PM, Richard Gaskin wrote:
> 
>> > I did write some compositing and blur/sharpen filters in
>> > transcript some time ago, but I don't know the details of
>> > the 'same-size chunk' replacements. Where can I find more info?
>>
>> All I know is what Dar posted here, but it sounded really tasty. 
>> Apparently he made a suggestion to Scott Raney about ways to optimize 
>> operations in which a string of a given length is used to replace a 
>> substring of the same length within a larger chunk.
>>
>> In previous versions a very generalized approach was used for all 
>> replacement operations, requiring that the data be copied during the 
>> replacement, which can be computationally expensive with large chunks.
>>
>> Since the data being inserted is the same length as the data being 
>> removed the handle size doesn't change, allowing the operation to work 
>> in-place, without copying.
>>
>> IIRC, Raney reported that the new method should improve speed by 
>> roughly 4000 times for those cases.
>>
>> Dar - got the details for us?
> 
> 
> You got the important parts.
> 
> For building a large string such as an image, the put-after command is 
> fastest (1 or 2 microseconds on my Mac).  So, if you are doing color 
> shifting on an image, that is the best to go.
> 
>    put newPixel after imageSoFar
> 
> But if you are putting a small image over a large image or drawing onto 
> an image or doing something that needs random access or a change to only 
> part, then use same-size put-into (6 microseconds on my Mac).
> 
>    put newPixel into char p to p+3 of imageSoFar
> 
> This used to take very long on large images.  Now both of these are 
> small fixed time.  (Well, there is a tiny growth time every once in a 
> while for 'after' but it is only a microsecond on my computer, that is, 
> it is fixed, too.)
> 
> Anyway, use 'after' if you can, and make sure the chunk sizes match if 
> you can't.
> 
> This also very handy for binary arrays and matrices and such.
> 
> I thought I had entered that as an enhancement into bugzilla, but either 
> I goofed or it was changed.
> 
> This is one of those things in which a fundamental enhancement or 
> performance improvement might open the doors to a scripting solution to 
> what is on folks' wish lists.

Good info, thanks Dar.

Chipp, does any of this apply to your image processing routines?

Anyone else here interested in seeing if it's now feasible to write 
efficient image filters in native Transcript?

--
  Richard Gaskin
  Fourth World Media Corporation
  __________________________________________________
  Rev tools and more: http://www.fourthworld.com/rev