Re: processing time & stack overflow!!!
Re: processing time & stack overflow!!!
- Subject: Re: processing time & stack overflow!!!
- From: Timothy Bates <email@hidden>
- Date: Sun, 02 Sep 2001 00:02:20 +1000
On 9/1/01 3:57 AM, "Stockly, Ed" <email@hidden> wrote:
>
There is nothing wrong with the AppleScript compiler.
Nothing? It is a Platonic Ideal? You are saying noone could possibly make a
compiler that compiles AppleScript to faster object code?
I sure am glad that the Zend people did not think that about php2 when they
took a nice fast language and got 10X performance out of it in php 4.
Or maybe the Apple's 1000 system engineers struggling to write OS X with an
outdated version of GCC (GNU C compiler) could simply tell themselves before
they go to bed "There is "nothing" wrong with our current version of GCC"
Or the National Instruments coders who have gotten C-like speeds out of
their fully parallel data-driven language, in no small part by optimising
and delaying data-copy operations so they are not done until proven
necessary by irreversable operations like list-item deletion.
Unfortunately reality bites. All of these real examples are about mission
critical software which has shown dramatic speed improvements because the
developers did not tell themselves "Oh, historically our product was not
designed to go fast" or "Only a minority of our need that kind of power" or
"Our users don't need this".
Instead they listened to their own hacker heart beat and its need-for-speed
and appreciation of cunning optimisations, and they watched and were
frightened by the hungry-eyed competition in the rear vision mirror.
>
AppleScript ... can "handle tasks" internally, it can use OSAX commands,
>
and it can use application commands.
>
Given this combination I would submit that AppleScript can handle nearly any
>
task that any other programming language can handle.
What you are saying is that your bicycle can go anywhere in the world as
long as you load it into a plane.
The average joe cannot write a script extension, or faceless background
application. Nor should they need to: Nine times out of ten, users on this
list have demonstrated that they can have a pretty good hack at writing what
they need in AppleScript and if someone would just fix it so that it can
operate at an acceptable speed this would BE the solution.
AppleScript's compiler is hopeless, not just because it copies data (when it
could look ahead in the script and see that all operations on the requested
data are simple reads and substitute a reference instead of a copy), but it
is hopeless at building lists, and handling large lists.
The compiler should look at loops with constants and guestimate a chunk of
memory to allocate which should be sufficient. This is often not possible in
a dynamic binding language, therefore, AppleScript also needs to allow the
user to take control of this, to pre-allocate memory for data. Here is a
concrete example which would speed many scripts by 2-10 fold.
i.e., this operation is going to be very slow
set x to {}
repeat while not done
set end of x to "1 more"
set done to (x > 10000)
end
Why? because the array is constantly going to exceed the memory allocated
and a COMPLETE NEW COPY will be created.
As I noted above, AppleScript could have some compiler options like
"pre-allocate large chunks for arrays" which would mean that many arrays
would waste memory, but few would be copied during creation.
But more effectively, we could add an initialization construct
set x to array of <anything> length <integer> default <anything>
then we could say:
set x to array of integers length 10000 default 0
set n to 1
repeat while not done
set item n of x to "1 more"
my doneEvaluator()
set n++
end
Of course, then we run into the slowness of simply setting and getting array
elements, but this too could get a 10X+ speed increase.
>
>>>> it is easier and more natural to work in one language as much as possible
>
>>>> rather than switching back and forth between a few or many, no?
>
Again, truly an advantage of AppleScript. Rather than learn a new language
>
for every application you need to script you learn only one language and
>
control hundreds of applications.
again, I would argue that too much of the funcitonal AppleScript "language"
resides in Applications and extensions and hence must be learned over an
over with new apps and extensions. A good example is the lack of whose
clauses in lists. These both:
a. make AppleScript hard to learn because Apple's own language does not
support the object model.
b. force us to use Apps like Tex-Edit when AppleScript should be plenty
good.
>
> But if the demand is really so strong, then someone ought to write a fast,
>
> highly scriptable FBA.
>
>>> what is an fba?
>
That's a "Faceless Background Application". A scriptable FBA can be used to
>
extend the language and provide tools, like text manipulation tools, for
>
Scripters. Many Scripters prefer FBAs to OSAX. They have similar purposes
>
but different approaches. An OSAX ads its command and its coercions to
>
AppleScript globally while an FBA must be addressed in a tell to use its
>
commands.
With an inherent clumsyness of scripting, and, has been demonstrated by
really adopters of this FBA replacements for OSAX under OS-X, VERY SLOW TO
TALK TOO ...
I would like for when Linux guys come into my office, or Windoze users, that
they are blown away, not just by what I am doing (combining brain imaging,
skin conductance, 250HZ eye-movement monitoring and perceptual testing
simultaneously using AppleScript), but also blown away by the blazing speed.
I would also like to be able to rationally choose AppleScript as my web
scripting language over php (which is syntactically more complex, but 100
times faster). You can count the number of AppleScript cgi's on one hand. We
should rule in this sphere: and if end users could use AppleScript embedded
in their Web pages (preferably with executable cross platform by porting OSA
to Linux, we would have a massive user community. And Apple would have a
great marketing tool equal to flash or PHP, and very attractive to people
using apps like Dreamweaver.
tim