Wilhelm Sanke wrote:
I tested these two scripts in versions 2.6.6 and 2.7.4 of Metacard and
the corresponding engine versions of Rev 2.6.1 and 2.7.4, both as stacks
and as standalones. The stacks were always launched from the same folder.
I again used a larger image of 1600 X 1200 which was reset each time
immediately after each run of a script.
Results (average numbers are given for several measurements in all
categories):
- MC 2.6.6: Measured inside is 300 milliseconds faster, both in the
stack and the standalone (9350 vs. 9050)
- Rev 2.6.1 (engine identical to MC 2.6.6)
Stack: measured inside is 3400 milliseconds faster (13200 vs. 9800)
Standalone: measured inside is 3500 milliseconds faster (12250 vs. 9050)
There is another difference here between standalone and stack in REV
2.6.1 indicating an additional interference from the IDE of about 1 second.
- MC 2.7.4
Stack: Measured inside is 300 milliseconds faster (9400 vs. 9100)
Standalone: Measured inside is also 300 milliseconds faster (9480 vs.
9180), but the standalone is slightly slower than the stack ??
- Rev 2.7.4
Stack: Measured inside is 3130 milliseconds faster (12860 vs. 9730)
Standalone: Measured inside is is 3200 milliseconds faster (12400 vs.
9200), and the standalone is somewhat faster than the stack.
As you can see when you compare the above data of MC 2.7.4 and Rev 2.7.4
there is an additional speed difference between the IDEs even when
"measured inside": Rev is here an extra 630 milliseconds slower, meaning
that this difference cannot be accounted for by imagedata handling, but
must be caused by other interfering scripts in the Rev IDE.
Overall conclusion: Rev is generally 3 seconds slower (33 %) when the
imagedata handling is included in the measurement. There is also an
additional interference from the Rev IDE.
Damn but that's thorough. Great work. Please make sure you include
those in the BZ report.
On further consideration, I share your hunch that it isn't related to
memory. I ran the same test with Activity Monitor set to display memory
usage, and it nowhere near spiked. Given the low frequency with which
AM updates that may not be precise, but I have enough memory free that I
doubt that's the issue.
To verify that the Rev scripts are the cause, one way would be to
include an initialization which purges all frontscripts and backscripts.
If it ain't in the message path it can't be triggered.
But still that leaves us with the core question of how any script could
be triggered from within the tight loop of your relatively small handler.
In my understanding, revCommon is a backscript only, and the only system
message it traps is mouseDoubleUp (not sure why this isn't in the
frontScript, but that's for another exploration). Everything else in
revCommon is inert in any standalone that doesn't explicitly call those
handlers.
Given what we know thus far, I'm wondering now if perhaps you've
discovered some undocumented "feature" in the engine which forks
execution depending on whether or not revCommon is present. Verifying
that would mean going back to v2.5 to test, and it's such a hair-brained
idea that it's not likely what's really happening anyway. I mention it
only because frankly I'm out of other ideas on what could be going on.
For the moment it may be most productive to just post your test and
results to BZ and let the folks at RunRev sort it out. As MC users
we're unaffected by this performance loss, and no one would benefit more
from pinning this down than the folks who have access to the source and
are therefore better equipped to delve into the inner workings of what's
going on.
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
