Re: AppleScript in Rosetta
Re: AppleScript in Rosetta
- Subject: Re: AppleScript in Rosetta
- From: Christopher Nebel <email@hidden>
- Date: Wed, 13 Sep 2006 01:41:41 -0700
On Sep 12, 2006, at 11:36 PM, Paul Berkowitz wrote:
I think Chris may be the only one who can answer this:
I know that AppleScript "just works" on both PPC and Intel, no
matter where
compiled (with the exception that PPC scripting additions won't work
on
Intel).
If a Bundle Script Application, which is automatically a Universal
app,
contains code in a tell block directed at a PPC-only app running in
Rosetta
on Intel, are there any speed or memory repercussions, compared to
code
directed at an Intel app (or no app), or to the same script running
on PPC?
How about a Carbon Script App running in Rosetta on his MacIntel?
The reason why I ask is that one one of my users just had a time-out
on a
command which tries to use a "whose" filter on a large "list" of
application
objects in a PPC app tell block. It may be simply due to the
enormous number
of items being filtered (20,000 Entourage contacts, compared to a
more usual
total of closer to 3,000). But his computer, a brand new MacIntel
with 1 GB
RAM, is not short on power.
The script is a Carbon Script Application. So far, I hadn't thought it
necessary to re-do the script as an Application Bundle, for two
reasons:
it's almost entirely directed at Entourage, which is still a PPC
app, and it
requires a PPC-only osax, which still works fine in the Carbon app
but would
not in a Bundle. (If you want to know, I licensed this osax for
shareware
use and the osax developers no longer do this with their Intel
version: my
users would have to fork out another $20 or so each for the osax,
which is
not acceptable.)
So far, no one on PPC has had this problem. That may just be because
no one
else has 20,000 contacts. But I've been wondering if maybe Rosetta
is part
of the problem and, if so, would it still be so if I were able to
provide a
Bundle version of the script app.
I thought we'd hashed this out when the Intel Macs were introduced.
Essentially, Rosetta-ed (emulated) processes are slower than
equivalent native processes. (Emulation does cost, after all.)
Therefore, you'll see a slowdown proportional to the amount of code
that you're running in emulation.
Where this gets tricky for scripts is that whenever you tell some
other application to do something, it's *that* application's native-vs-
emulated status that matters, not yours. Therefore, if you tell an
emulated application -- say, Entourage -- to do something huge, it
won't make any difference whether or your script is saved Universal or
not. (Well, that's not quite true. If the amount of data coming back
to your script is really large, then it'll pay for your script to be
native, because that data gets handled in your process. However, that
happens after the event reply comes back, and therefore isn't subject
to timeouts.)
The first thing I'd check is, if you boost the timeout for this case,
does it eventually come back with the correct answer? Entourage may
just be completely gagging.
--Chris Nebel
AppleScript Engineering
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden