RE: Why are compiled scripts slower than from Script Editor?
RE: Why are compiled scripts slower than from Script Editor?
- Subject: RE: Why are compiled scripts slower than from Script Editor?
- From: "Sprague, Graham" <email@hidden>
- Date: Tue, 25 Mar 2003 10:36:54 -0500
So is there any one else out there who can who can help with this. The
original question was: Why do compliled apps run slower than compiled
scripts run from within the Script Editor?
The Facts...
Mac OS X 10.2.4
Quark 4.11 (Classic)
FileMaker 6.0v4 (Native)
Script Editor 1.9
Compiled App does not have "Require Classic" checked.
Compiled App runs at least 4x slower than when run from Script Editor
TruBlueEnvironment uses 20-30% of CPU when run as a compiled app
TruBlueEnvironment uses 60-70% of CPU when run from Script Editor
Anyone else having this problem?
>
----------
>
From: Patrick S. Page-McCaw
>
Sent: Wednesday, March 19, 2003 5:48 PM
>
To: email@hidden
>
Subject: Re: Why are compiled scripts slower than from Script Editor?
>
>
I've lost track of the thread I started, I hope this is not
>
duplicative. I'm close to giving up on AppleScript for this purpose
>
and moving to writing my own java app. Oh well.
>
>
>
Andrew Oliver wrote:
>
>When running in Script Editor, you have the memory block assigned to SE
>
to
>
>play with (which almost every scripter would have increased from the
>
>default).
>
>
>
>When running as a compiled app, you'll have whatever memory allocation is
>
>applied to the app - it's been a long time since I've used 9.x but 384K
>
>comes to mind.
>
>
>
>Try upping the memory allocation for your script app and see if you see
>
the
>
>same results.
>
>
The script I used is available if you want it (delayIt() is just a
>
repeat loop like the one Andrew suggested). The times for the repeat
>
loop are (asked for 500ms loop):
>
>
type mean times (ms) st dev (ms) OFFSET
>
---- ----------- ------ ------
>
in ed 501.2346939 1.420040804 1.2 +/- 1.4
>
200k 548.7979798 7.282884322 49 +/- 7.3
>
2000k 548.5510204 6.547404379 49 +/- 6.5
>
>
and by 'type' I mean, how the script was run: in the editor (here
>
SMILE), as default size (200k), or with the size (minimal and
>
preferred) increased by 10-fold.
>
>
I find it hard to believe that the size would matter. There is only
>
one list 'myLog', it is not long and the loop interval time does not
>
increase with iterations.
>
>
So, to my mind something is wrong. Compiled scripts just should not
>
take longer than non-compiled scripts. I dont know about other apps
>
hogging the priority queue, that could be part of the trouble. It is
>
certainly true that occasionally for all three apps there are very
>
long intervals, if Explorer or Eudora (or some others) are running in
>
the background. But those events are easy to see, they are outliers.
>
For the examples above the time values vary consistently about the
>
mean by app the st dev. (For those who care: The st dev is not a good
>
approximation of the variance in the data as the distribution of the
>
data is not gaussian, but it does give a sense of the range.)
>
>
Still in all, the time for the loop in the editors is very impressive
>
(for a scripting language) and even with lots of stuff happening
>
(including waiting for the device!) in my serial port
>
writer/controller , the offset only increases to about 7 ms (again
>
with good consistency). (More data for those who care: in 39 runs of
>
42 cycles each 85.8% of the events were on time (within 1 ms), less
>
than 0.2 % were early , 92% were no more than 3 ms late, 99.0% were
>
no more than 10 ms late, and the last three events were at 15, 17,
>
and 19 ms late.)
>
>
But if you can't compile it, what's the point? So I've been learning
>
Java and looking into other platforms (which are very much faster ,
>
at the same clock speed, see
>
http://rsb.info.nih.gov/ij/plugins/plasma.html)
>
>
( a message for those at Apple who might be thinking about markets )
>
Biologists (molecular, cellular, biochemists, geneticists) are just
>
about the last scientists using Macs consistently (as far as I can
>
tell), maybe the marketing people at Apple have decided that we are
>
too small a market or that we are already converting too quickly to
>
be worth holding on to. Whatever. Most of the biologists that I know
>
really don't ever want to deal with UNIX and Windows. More and more
>
of our data takes the form of computer files of one kind or another.
>
Often lots and lots of files, that need processing in bulk. Gee,
>
wouldn't it be nice if we had a scripting language that could do that
>
processing? But we do (Applescript) but no one knows about it (or if
>
they do, they think its a joke). Thats sad.
>
>
So I hope this gets through to the people making decisions. None of
>
the uNIX/ Win heads here believe that Macs can do what I am doing
>
with them. Nor do they believe that you can do it all for free (ok I
>
shelled out for a Sony handicam), most equivalent systems would run
>
$20k.
>
>
If you (in marketing) are interested in what we are looking for, give
>
a holler. But do it soon, you are losing your market share fast here.
>
>
(end pointed message)
>
>
Thanks for keeping my thread alive,
>
>
Patrick
>
--
>
>
>
__________________________________________________________________________
>
_
>
Patrick S. Page-McCaw
>
University of California, San Francisco
>
Department of Physiology, Box 0444
>
513 Parnassus Avenue, Room S-864
>
San Francisco, California 94143-0444
>
>
phone: 415 476-8367
>
fax: 415 476-4929 attn P. Page-McCaw
>
email: email@hidden
>
_______________________________________________
>
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.
_______________________________________________
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.