Re: Damn send button / Wind chill (nesting more efficient shock)
Re: Damn send button / Wind chill (nesting more efficient shock)
- Subject: Re: Damn send button / Wind chill (nesting more efficient shock)
- From: John W Baxter <email@hidden>
- Date: Mon, 4 Mar 2002 08:04:11 -0800
At 21:45 +1100 3/4/2002, Shane Stanley wrote:
>
I guess the moral of this, and other postings that show that some things
>
that were faster are now slower, is not to worry too much about it. In
>
reality, if you're scripting an app, there's a good chance that the bulk of
>
the overall time is taken by the app doing it's work.
Hear, hear. If one is only doing something once or a few times, only
*really large* speed differences matter. It's only in loops that
micro-optimization makes sense...and for the Scripting Addition case, that
optimization is usually to drop out of all tells to run the OSAX.
Why "usually"? One would have to measure a case in which several values
are extracted from an application, run through a single OSAX call, and the
result(s) fed back to the application. Is it "better" to keep the OSAX
call within the tell, or better to find a way to present the inputs to a
naked osax call and feed the results to the application.
Is
tell application "Foo"
set ... to my handlerWithNakedOSAX(....)
end tell
a call of a naked scripting addition, or is the call inside the tell. I
think it's a call to a naked addition, but I haven't measured.
Outside of a loop, I wouldn't bother measuring: I'd leave the osax call
inside the tell for readability, or write the handler for
readability...whichever seems more readable. (Do I have to massage the
values from the application before passing them to the Addition? Same for
the result(s)? Does the Addition have a sensible name? etc)
--John
And, of course, the 20,000 calls in a row to current date (as in my tests)
are simply silly. [In early System versions, they were downright
dangerous: there was a bug which caused repeated accesses to the clock to
freeze the machine, which was the root of the Netscape freeze problem
solved by the "Netscape Defrost" extension. Really, only a single access
to the clock was needed to freeze the machine, but with low probability.
Repeatedly testing the time zone as the Netscape code did raised the
probability of freezing (lowered the overall probability of not freezing).
Netscape: "my goodness...has this machine moved to a different
timezone...we'd better check!"]
--
John Baxter email@hidden Port Ludlow, WA, USA
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.