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

[Richard Gaskin]

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