Re: Not so sure (was Re: Scott Norton is brilliant (was: solutions to scripting addition t erminology confilicts))
Re: Not so sure (was Re: Scott Norton is brilliant (was: solutions to scripting addition t erminology confilicts))
- Subject: Re: Not so sure (was Re: Scott Norton is brilliant (was: solutions to scripting addition t erminology confilicts))
- From: has <email@hidden>
- Date: Sat, 26 Jan 2002 01:28:49 +0000
Michael Sullivan wrote:
>
Do osaxen have any speed advantages over apps?
>
>
It strikes me that they don't -- they still involve an apple event call,
>
it's just to the system instead of an app. Maybe that makes it
>
marginally faster, but it still takes aeons compared to a straight
>
language command.
IIRC, in a reply to one of my own posts a couple months' back, Scott
mentioned that a call to an osax is 1/100th the speed of a call to a local
handler, and that a call to an application is 1/10th the speed of a call to
an osax. So the answer would be yes.
>
My feeling is that I'd like to be able to attach osax (or similar) code
>
directly to a compiled script so that the script can call it without any
>
apple event overhead.
How do other languages manage to hook chunks of compiled C code into native
script? Seems to me you'll always have some sort of overhead connecting the
two. Anyone?
>
ASCII number/character is a perfect example. If it could be executed at
>
the speed of a typical set command on a number or short string, it would
>
eliminate the need for hacks such as Arthur's that make use of the
>
record as list as string feature^H^H^H^H^H^H^Hbug.
Personally, I wouldn't use Arthur's hack (sorry Arthur;) simply because
it's impossible to guarantee that it will work on all machines now and in
the future (it seems tough enough vouching for standard code these
days...). But even a non-hack method will outstrip these osax calls several
times over, so replacing these calls with native code is an advantage in
speed-critical routines. Where they score is in convenience (one line
versus many), which is the main point of having them, I suppose.
>
The osax as it exists is fine for very scripts, but utterly useless for
>
heavy text manipulation. All because of the apple event overhead in
>
calling an osax.
Depends what sort of manipulation you're doing, I suppose. Other scripting
languages may be more suitable for a particular task - 'heavy text
manipulation' isn't exactly AS's strongest suite to begin with. To be
honest though, I suspect the biggest 'overhead' is simply that which comes
from using an interpreted - as opposed to compiled - language in the first
place. C'est la vie.
Oh, and I nominate Scott for the "scariest AppleScripter of the year"
award. Yike!
has
(Excitedly awaiting the v1 release of NortonScript, any day now...;)