why is appleScript so slow!
socko
just written a very short script that changes the names of all the files in
a folder. for 25 files, the AppleScript script takes about a minute and a
half. by contrast, performing the same task in OneClick runs in less than 3
seconds. what gives? why so slow?
copies of both scripts listed below as an FYI
APPLESCRIPT ------------------------------
on open (myFolder)
set mySuffix to text returned of (display dialog "Suffix to add:" default
answer " Copy")
AppendSuffix(myFolder as alias, mySuffix) end open
on AppendSuffix(myFolder, mySuffix)
tell application "Finder"
set myFolderContents to every file of myFolder
repeat with x in myFolderContents
if name of x does not end with mySuffix then
try
set name of x to (name of x & mySuffix)
end try
end if
end repeat
if number of folders in myFolder > 0 then
repeat with y in every folder of myFolder
AppendSuffix(y, mySuffix) of me
end repeat
end if
end tell end AppendSuffix
ONECLICK SCRIPT (for the curious and/or OneClick scripters
------------------------------------
On DragAndDrop
Variable fileCount, x, fileList, fileName, test
Directory = GetDragAndDrop
fileCount = File(Directory).Count
fileList = File(Directory).List
For x = 1 To fileCount
// fileCount
fileName = ListItems fileList, 1, 1
test = Find ".fp5 Copy", fileName
If test > 0
test = Replace " Copy", fileName, ""
File(Directory & fileName).Name = test
Else
File(Directory & fileName).Name = fileName & " Copy"
End If
fileList = ListDelete fileList, 1, 1
End For End DragAndDrop
ordak
Don't use the Finder! Use Jon's Commands to "renameFile"
and use list Folder to get the contents of the target folder, with
one handler to process folders and another handler to process
files within. Or just use Jon's walk folders.
If you leave the event log open you will notice that each call to
the Finder generates an AppleEvent. Minimizing them speeds things up.
cheers
socko
ordak
> who is Jon, and where can his commands be found?
Jon Pugh.
His osax, and most others can be found at
http://www.osaxen.com
cris
> i've never understood why appleScript runs so slowly! for instance, i've
> just written a very short script that changes the names of all the files in
> a folder. for 25 files, the AppleScript script takes about a minute and a
> half. by contrast, performing the same task in OneClick runs in less than 3
> seconds. what gives? why so slow?
Try:
ignoring application responses
set name of x to (name of x & mySuffix)
end
Greetings
cris :-)
--
English is my second language. Please write slowly!
www.cooc.de
ordak
nice call :> but file names remain the same!
Marc K. Myers
I played around with this for a while and came to the conclusion that
the Finder is just inherently slow doing name changes. Mine didn't take
anywhere near as long as yours did, but if I commented out the part that
actually changed the names the rest of the script took 4 seconds to
process 34 files in nested folders. With the name change code left in
it took 10 seconds. Using a scripting addition to mine the nested
folders only shaved a second off the total time.
Marc K. Myers <Ma...@AppleScriptsToGo.com>
http://AppleScriptsToGo.com
4020 W.220th St.
Fairview Park, OH 44126
(440) 331-1074
[6/30/01 5:43:10 PM]
ordak
wrote:
Hi Mark
I played around with it too. With a folder hierarchy of 80 files:
(one try each, not a scientific test!)
Using the original thread's Finder method it took 180 seconds
Using a script based on SD's Folder Scanner droplet and Jon's rename File
it took 36 seconds
Using Jon's Walk folder it took 28 seconds.
I usually call the Finder only for things that there is no other way to do.
ordinary ordak
socko
From: "Marc K. Myers" <Ma...@ChezMyers.com>
Organization: [very little]
Reply-To: Ma...@ChezMyers.com
Newsgroups: alt.comp.lang.applescript
Date: Sat, 30 Jun 2001 17:44:40 -0400
Subject: Re: why is appleScript so slow!
ordak
<so...@rocketmail.com> wrote:
> actually, i had modified this script from its original form so it could be
> compared to a OneClick routine. what i'm actually doing is changing the
> label to 1. but it, too is extremely slow. i have gotten some good
> feedback from several of you out there, and the feedback is much
> appreciated. still, it surprises me that Apple can't make these extremely
> basic interactions with its own OS happen more quickly without necessitating
> extra gyrations or OSAX integration by the script programmer.
It's no fault of the Finder as such. If it is possible to do the deed with
the least
number of AppleEvent calls then there is a speed gain to be realized.
A good example is Filemaker:
--Given 10 records of 10 cells
a) One can create a new record and set every cell of the record with one
AE call per record (10 Calls)
or
b) create a record and set each cell of the record one at a time with one
AE call per cell (100 calls)
Method b is painfully slow.
So in your example with the Finder, if the script can be written so that
all labels can be
set at once for the files matching the criteria, it would work much faster.
I would think that osaxen like (Jon's, Akua) do it by directly making low
level calls to the file system.
But then again some osaxen actually do their thing slower than pure AS code!
hth
and I'll leave lot's of space down here for corrections by others ;>
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
-->
Marc K. Myers
I just tried my version of the script that uses "the entries in" to mine
the nested folders and substituted "renameFile" for the Finder rename.
It actually ran two seconds longer using the scripting addition! Weird!
Marc K. Myers <Ma...@AppleScriptsToGo.com>
http://AppleScriptsToGo.com
4020 W.220th St.
Fairview Park, OH 44126
(440) 331-1074
[6/30/01 7:36:34 PM]
cris
> > Try:
> >
> > ignoring application responses
> > set name of x to (name of x & mySuffix)
> > end
>
> nice call :> but file names remain the same!
You're right. It doesn't work because you call the finder for the name
of the file inside the ignoring part. It works if you set the name to a
constant or if you grab the name before - but i don't know if you get
still enough advantage in speed then:
tell application "Finder"
set filelist to every file in folder "sys:Desktop
Folder:untitled folder:"
set mySuffix to 0
repeat with i in filelist
set {mySuffix, temp} to {mySuffix + 1, name of i}
ignoring application responses
set name of i to (temp & mySuffix) -- (name of i
& mySuffix)
end ignoring
end repeat
end tell
Simon Slavin
"Marc K. Myers" <Ma...@ChezMyers.com> wrote:
> I played around with this for a while and came to the conclusion that
> the Finder is just inherently slow doing name changes.
The Finder is inherently slow at everything. It is multitasking
and is expected to provide user-feedback (i.e. to show the name
change to the user if the appropriate window is open).
Simon.
--
http://www.hearsay.demon.co.uk | I have a hunch that [] the unknown sequences
No junk email please. | of DNA [will decode into] copyright notices
| and patent protections. -- Donald E. Knuth
Mac OS X. Because making Unix user-friendly is easier than debugging Windows.
Marc K. Myers
On another forum, someone suggested that I try the "rename" osax from th
GTQ Scripting Additions. It flew! Whatever was slowing down the Finder
and renameFile (Jon's Commands) didn't seem to apply to the one from GTQ.
Marc K. Myers <Ma...@AppleScriptsToGo.com>
http://AppleScriptsToGo.com"
4020 W.220th St.
Fairview Park, OH 44126
(440) 331-1074
[7/3/01 1:46:11 AM]
Thravis
a random color. It was slow as a compiled script, but I pasted it into a
oneclick button and it ran like 5 times faster. What's the deal with that?
travis
ordak
(Thravis) wrote:
Compiled script or Applet?
What context?
Run as an applet there is the overhead of Applet--> App communications
run from oneclick, (from a palette associated with the app) the code is
running in the same context as the app.
--
ordak
Javier Bezos
> In article <3b3e49df$0$62145$4c5e...@news.erinet.com>,
> "Marc K. Myers" <Ma...@ChezMyers.com> wrote:
>
> > I played around with this for a while and came to the conclusion that
> > the Finder is just inherently slow doing name changes.
>
> The Finder is inherently slow at everything. It is multitasking
> and is expected to provide user-feedback (i.e. to show the name
> change to the user if the appropriate window is open).
I don't think so. AppleScript _is_ very slow when renaming files,
and that's not a problem with the Finder. Renaming several
thousand files with Python takes a few minutes (2 or 3)
but one hour and a half with AppleScript. With Python the
system is still reliable and names and icons (if you change the
type/creator as well) are inmediatly updated, so indeed the
problem is AppleScript. (No flame war--I use AppleScript
or Python depending on the task. I like both.)
Regards
___________________________________________________________
Javier Bezos | TeX y tipografia
jbezos at wanadoo dot es | http://perso.wanadoo.es/jbezos/
...........................................................
CervanTeX http://apolo.us.es/CervanTeX/CervanTeX.html
Patrick Stadelmann
see....@no.spam.es (Javier Bezos) wrote:
> <sla...@hearsay.demon.co.uk> wrote:
>
> > In article <3b3e49df$0$62145$4c5e...@news.erinet.com>,
> > "Marc K. Myers" <Ma...@ChezMyers.com> wrote:
> >
> > > I played around with this for a while and came to the conclusion that
> > > the Finder is just inherently slow doing name changes.
> >
> > The Finder is inherently slow at everything. It is multitasking
> > and is expected to provide user-feedback (i.e. to show the name
> > change to the user if the appropriate window is open).
>
> I don't think so. AppleScript _is_ very slow when renaming files,
AppleScript doesn't actually rename the files, it just asks the Finder
to perform this task. Given the fact tha AS can send several dozens
command to the Finder in one second on my G3/233, the problem clearly
lies in the Finder.
Patrick
--
Patrick Stadelmann <Patrick.S...@unine.ch>
Greg Weston
<see....@no.spam.es> wrote:
> > The Finder is inherently slow at everything. It is multitasking
> > and is expected to provide user-feedback (i.e. to show the name
> > change to the user if the appropriate window is open).
>
> I don't think so. AppleScript _is_ very slow when renaming files,
> and that's not a problem with the Finder. Renaming several
> thousand files with Python takes a few minutes (2 or 3)
> but one hour and a half with AppleScript. With Python the
> system is still reliable and names and icons (if you change the
> type/creator as well) are inmediatly updated, so indeed the
> problem is AppleScript.
What leads you to believe that Pytthon is renaming files by sending
commands to the Finder instead of just making API calls?
G
Thravis
thousand files with Python takes a few minutes (2 or 3)
but one hour and a half with AppleScript. With Python the
system is still reliable and names and icons (if you change the
type/creator as well) are inmediatly updated, so indeed the
problem is AppleScript. (No flame war--I use AppleScript
or Python depending on the task. I like both.)
>>
hey, someone who uses python and a macintosh! How did you go about learning
python? Point me in a direction.
travis
Javier Bezos
> hey, someone who uses python and a macintosh! How did you go about learning
> python? Point me in a direction.
Python was first developped on a Mac! Formerly I used Tcl, but MacTcl
is not well supported and when I tried to run the latest releases
the system crashed. I was pointed to Python by a person and,
despite the way it marks blocks, it's a nice language. Sadly,
its interface to OSA has some flawes and is difficult to grasp
(AppleScript is crystal clear here).
See www.python.org
Regards
Javier
Javier Bezos
No, no. Python makes API calls
>
> G
Javier Bezos
Ooops! The message was not finished.
Python makes API calls. I wonder why AppleScript doesn't include
a similar device, given the fact that the current method is
soooo slow.
Regards
Javier
Patrick Stadelmann
see....@no.spam.es (Javier Bezos) wrote:
> Python makes API calls. I wonder why AppleScript doesn't include
> a similar device, given the fact that the current method is
> soooo slow.
Just use an AppleScript addition, eg Jon's Command.
Greg Weston
<see....@no.spam.es> wrote:
> Python makes API calls. I wonder why AppleScript doesn't include
> a similar device, given the fact that the current method is
> soooo slow.
Easier to rely on the name validation logic in the Finder than to have
AS be able to recognize the system it's on any be aware of any niggling
little details. You can do things with API calls that end up making the
file fairly useless - or not even available - to the user.
socko
From: Greg Weston <gwesto...@CAPShome.com>
Organization: Excite@Home - The Leader in Broadband http://home.com/faster
Newsgroups: alt.comp.lang.applescript
Date: Fri, 06 Jul 2001 12:24:41 GMT
Subject: Re: why is appleScript so slow!
Michael Breslau
so that its capabilities can be used/invoked by another, unrelated
program.
For example, a database probably supports SQL statements, which are
'universal' but have to be decoded and interpreted. It may also provide
API calls to get or put data directly in binary--which is much faster.
In article <B76B3F0E.A2FF%so...@rocketmail.com>,
socko
Marc K. Myers
API are generally operating on a much lower level than Apple Events.
They are directly accessing subroutines without a lot of overhead in
other processing. That's why application's (or Scripting Additions)
using APIs can be faster than using AppleScript to access applications
at a command level. I'm not a Mac programmer, but it seems that
scripting commands use much the same code as the same commands executed
through the user interface.
Marc K. Myers <Ma...@AppleScriptsToGo.com>
http://AppleScriptsToGo.com"
4020 W.220th St.
Fairview Park, OH 44126
(440) 331-1074
[7/6/01 8:39:50 PM]
socko
> From: "Marc K. Myers" <Ma...@ChezMyers.com>
> Organization: [very little]
> Reply-To: Ma...@ChezMyers.com
Greg Weston
Michael Breslau <mbre...@speakeasy.org> wrote:
> Application Program Interface. It's a means one program furnishes
> so that its capabilities can be used/invoked by another, unrelated
> program.
To be nitpicky, the standard use of API doesn't refer to an interface
provided by a program. It generally indicates the interface to the
operating system and related services. Generally. The term _is_
ambiguous enough that it could reasonably cover interfaces from other
apps.
G
like i would tell you
> socko <soc...@yahoo.com> wrote:
>
> > i've never understood why appleScript runs so slowly! for instance,
> > i've
> > just written a very short script that changes the names of all the
> > files in
> > a folder. for 25 files, the AppleScript script takes about a minute and
> > a
> > half. by contrast, performing the same task in OneClick runs in less
> > than 3
> > seconds. what gives? why so slow?
>
> Try:
>
> ignoring application responses
> set name of x to (name of x & mySuffix)
> end
>
>
>
> Greetings
> cris :-)
Becasue Apple Script is a high level programming language that takes
time to run due to the fact that it must interpret the commands, read
scripting plugins, and figure out what and the hell it's doing!!!
--
-- Please don't send me email
zurg
<ask...@please.invalid> wrote:
> > > i've never understood why appleScript runs so slowly! for instance,
> > > i've
> > > just written a very short script that changes the names of all the
> > > files in
> > > a folder. for 25 files, the AppleScript script takes about a minute and
> > > a
> > > half. by contrast, performing the same task in OneClick runs in less
> > > than 3
> > > seconds. what gives? why so slow?
> Becasue Apple Script is a high level programming language that takes
> time to run due to the fact that it must interpret the commands,
True, but as is usually the case, speed and efficiency has less to do
with the programming/scripting environment and more to do with the
programmer's knowledge of the language and its quirks and conventions
as well as the kind of machine it's being run on and whether or not any
of the software or background processes/extensions are interfering.
Coincidentally, I wrote a script that is similar to the one described
above. In fact, mine not only renames the files but copies them to
another part of the network and then moves the originals to another
folder. Typically, we're dealing with 25 files at a time so it's
comparable to the situation described above.
It doesn't take anywhere near a minute-and-a-half, maybe 20 seconds or
so and most of that is due to the copying. I'd be curious to see the
script above. I'll bet it can be optimized in some way. If not, I would
wonder what version of Applescript is being used and what kind of
system it's being run on as well as what sort of extensions and
software are running at the same time. Those are valid considerations
and don't necessarily reflect on the inherent speed of the scripting
language.
FWIW, I find Applescript sufficiently and consistently speedy for most
purposes.