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>
_______________________________________________
metacard mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/metacard
