Re: Speeding Up Script
Re: Speeding Up Script
- Subject: Re: Speeding Up Script
- From: Chris Nebel <email@hidden>
- Date: Thu, 23 Nov 2000 00:45:43 -0800
- Organization: Apple Computer, Inc.
"Mr. Weasel Willits" wrote:
>
on run {fileName}
>
--ignoring application responses
>
tell application "Finder" to return (position of item fileName of
>
desktop)
>
--end ignoring
>
end run
>
>
I'm using this script in REALbasic and it will be run tens of times. I wish
>
I could ignore responses to SIGNIFICANTLY speed up the action, but obviously
>
I can't. Is there some other way to speed this up or do I have to learn
>
alllllllllllll about AppleEvents and spend my four day weekend trying to
>
translate it???
>
>
Does anyone know AppleEvents and would be willing to translate that for me?
You can find out exactly what AppleEvents a script is sending by using some
sort of event watcher. I use MacsBug's "aevt" command myself, but AETracker
works perfectly well for most purposes. The event is pretty straightforward as
AppleEvents go:
Class: core ID: getd Target Type: psn "Finder"
KEY TYPE LENGTH DATA
---- obj 0000D0
KEY TYPE LENGTH DATA
form enum 000004 prop
want type 000004 prop
seld type 000004 posn
from obj 00008C
KEY TYPE LENGTH DATA
form enum 000004 name
want type 000004 cobj
seld TEXT 000008 <your text here>
from obj 000044
KEY TYPE LENGTH DATA
form enum 000004 prop
want type 000004 prop
seld type 000004 desk
from null 000000
However, I suspect that turning the script into a direct AppleEvent call won't
help that much -- the script makes exactly one AppleEvent call to the Finder as
it is, so you'd only save the overhead of calling AppleScript itself. There
are a few other ways to tackle this:
First, make sure you're optimizing the right thing. If you're calling this
script with the same item over and over, consider calling it just once and
saving the result. One of the best ways to reduce a function's performance
impact is to call it less often.
Assuming all the calls are for unique items, you've got to find a faster way to
get your answer. An item's position in its enclosing window (or the desktop,
in this case) is stored in the file's Finder info. The Finder lets you get
this, obviously, but so does "info for", which is faster than the Finder,
especially if you send the event to yourself. Try replacing your script with
this one:
on run filename
icon position of (info for file ((path to desktop as string) &
filename))
end run
As an AppleEvent, it looks something like this:
Class: syso ID: nfo4 Target Type: psn kCurrentProcess
KEY TYPE LENGTH DATA
---- obj 00005E
KEY TYPE LENGTH DATA
form enum 000004 name
want type 000004 file
seld TEXT 00001E Tukuul:Desktop Folder:incoming
from null 000000
(I'm omitting the first event to get the path to the desktop. An obvious
optimization is to move the "path to desktop" into a property so it's only
called once instead of every time. That only saved me 5%, though, so I didn't
bother -- it introduces potential problems depending on how REALbasic works and
how often you move the script around. If you can come up with an FSSpec or an
alias to the file, then putting that in the direct object will work just as
well. Better, actually, because it'll be slightly faster.)
If REALbasic has some way to get the Finder info for a file, then you can just
use that directly, and not mess with AppleScript or AppleEvents at all.
--Chris Nebel
AppleScript Engineering