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: "Patrick S. Page-McCaw" <email@hidden>
- Date: Wed, 19 Mar 2003 14:48:30 -0800
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.