Speed differences between MC and Rev (problem area nearly found)

[Wilhelm Sanke]

Richard Gaskin wrote:

> Confirmed in the IDEs -- 5740ms/avg in MC, 6830ms/avg in Rev (I have a
> 1GHz PB G4).
>
> I haven't built standalones, though, which would be good to test. 


In the meantime I did further tests and built standalones for MC 2.6.5, 
2.73, 2.74 and Rev 2.6.1, 2.73, 2.74. I tested 3 more scripts and also 
tested all scripts with a much larger image of 1600 X 1200.
As before, no significant differences between stacks and standalones in 
MC and - also as before - a slight improvement for the Rev standalones 
compared to the Rev stacks, but a remaining difference to the MC 
equivalents of up to four seconds, and even one script where Rev runs 
*eleven* times slower than MC! See below.

>  Given this speed loss I'm confident the folks at RunRev will take a keen
> interest to determine what's eating performance.
>
> Offhand I can't imagine how the execution of a single handler with no
> breaks, pauses, or sends is in any way affected by any outside script,
> but it does indeed appear to be the case.
>
> Have you BZ'd this?  It would be good to include that file as an
> attachment to the report.


I might do this after some more research

> -- Richard Gaskin Fourth World Media Corporation


and Chipp Walters (on Wed, 11 Oct 2006) wrote:

> Wilhelm,
>
> Just wondering, did you 'lock messages' before and 'unlock messages'
> after when running the script? If not, you might want to try it and
> see if it doesn't speed things up.


Inserting "lock messages" etc. does not change the results.
But thanks for the hint, because the fact that adding "lock messages" 
does not change the speed means that the long

"setProp cREVGeneral [pwhichProp] pWhichProfile" handler

(which belongs to the scripts added by the Rev Standalone Builder) 
cannot be the culprit.
Unfortunately, all these extra scripts apparently are added by the 
script-protected revsaveasstandalone substack. I searched the scripts of 
the "StandaloneSettings" stacks and so far found nothing there that 
could be related to the speed difference problems.

> Also, you probably want to make sure 'Variable Checking by Default" is
> turned OFF in the prefs pane for RR.

Same as above, does not make any difference.

> best, Chipp



Here are some results for filters applied to the larger 1600 X 1200 
image (again: Windows computer with 2 GHz):

- "duplicate colors": Rev is * three seconds* slower in all the 3 stacks 
and standalones ( 9 vs. 12 and 10 vs. 13 seconds with different engine 
versions)

- "max dots" (this is a modified version of the Gimp "despeckle"-median 
filter, where I exchanged the median for the max values. The button is 
to be found in my Imagedata Toolkit below the "despeckle" filter).
Rev is about 4 seconds slower here, the results being 34 seconds for MC 
and 38.5 for Rev on the average.

I then happened to notice that the reset button worked considerably 
slower in Rev, eleven times slower, and I measured this.

The script of  the reset button is a one-liner

"set the imagedata of img 1 to decompress(the Bilddaten of me)" -- 
("Bilddaten" being a translation of imagedata).

This takes 270 milliseconds in MC and 3000 milliseconds in Rev with all 
engine versions and identical in stacks and standalones.

I removed "compress" for setting the custom property and "decompress" 
then in the reset handler, which didn't make much of a difference: Rev 
is now only 10 times slower.--

Anyway, after the "compress-decompress-reset" tests, I made some 
progress in detecting what is involved in producing the speed-difference 
problems. Instead of the image I placed a field with a longer text on 
the card, which then was saved as a custom property of the reset button. 
Resetting the text of the field is indeed identical in all Rev and MC 
stacks and standalones, meaning

that the speed differences between MC and Rev are caused by a different 
handling of "imagedata"!

It now remains to be found out which script is responsible for this 
abject treatment of imagedata in Revolution, where this script is 
located, and how we can prevent its interference.

Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>