[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] Mac OS 8.5



Pudge <pudge@pobox.com> writes
>I notice considerable speed improvements across the boards, and Apple
>Events themselves seem much faster.  Mac::Glue works fine with no changes;
>of course, now I will be troubled by how to release a Mac::Glue::Finder
>that works for everyone.  :/  Pain in the butt, but I am not thinking
>about Mac::Glue this weekend, so it is OK.  :-)

it will be interesting to see some figures, but here's a reply I got on the
macscripting list from an Apple engineer asking about this. The bottom line
is that while AppleScript is considerably faster in MacOS 8.5, there's been
no specific changes to AppleEvents. This is a pity for those of us
scripting in languages other than AS, but using AppleEvents to drive other
software. Unfortunately there was no followup to this posting from other
people, because I'm surprised at the implication a G3 can't really handle
more than 20 events/sec. I think Copland was supposed to do several
thousand per sec.

>>I know AppleScript is supposed to run 2-5 times faster, primarily
>>because mode switches have been significantly reduced, but I can't
>>remember whether AppleEvents have also gone native. What's the scoop?
>
>No, the Apple Event Manager (AEM) hasn't gone native yet.  For this to
>happen, and for the change to make much of a difference, there are a
>number of other managers which would need to go native, such as the
>Process Manager, PPC Toolbox, EPPC.
>
>Also, I would be willing to wadger that a native AEM wouldn't make all
>that much difference.  Even on an early PPC system the AEM can manage to
>send over 60 round trip Apple events per second.  Most scriptable
>applications don't seem able to manage to respond to more than 20 per
>second.  It did a bit of testing with a G3/266 asking the Finder for the
>name of the startup disk, a fairly simple operation, and the best I got
>was around 18 events per second.
>
>In most cases the bottle neck in Apple event performance is the amount of
>work the target application has to do to get a reply ready and sent back.
> When a script uses a whose clause the application has even more work to
>do.



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch