Home | Articles
Index
Previous Page
3. Use Compiled Code
HyperTalk version 2.x will compile handlers the first time they are
run. As long as HC has sufficient memory, it will keep the compiled code
in memory, making subsequent calls to the handler run much faster than
the first time.
However, externals are snippets of compiled
code, usually written in C, Pascal, or CompileIt! These run as fast as
computerly possible. As long as the external uses few HyperCard callbacks,
the external probably runs much faster than native HyperTalk.
What's a callback??? I hear
you ask? Well, sometimes an external needs to know something about HyperCard
and/or the stack, or needs HyperCard and/or the stack to do something.
For example, an external might need HyperCard to evaluate an expression,
such as "the short name of this card." Only the Chosen Few at
Apple and Claris know HyperCard's internal file and memory format and are
able to get this information directly. The rest of us have to ask HyperCard
to give us this information. The process of calling the external, the external
asking HyperCard a question, HyperCard answering, and the external doing
whatever it needs to do with the information, is a slower process than
HyperCard's just giving us the information in a handler. If an external
has a lot of callbacks, the extra time required for the callback could
reduce or eliminate the speed advantage of using an external in the first
place.
A timed example is presented in the "HyperCard Speed" stack.
4. Workaround Limitations
HyperCard has some undocumented limitations that only become apparent when you start working with large stacks (around 300 to 500 cards and more), or containers with a large number of items in them (3,000 to 5,000 words if you are working with words; 3,000 to 5,000 characters if you are working with characters, and so on).
a) Limitations of navigating by card name
I found that a stack's navigation slows down dramatically when a stack
I was working on reached about 300 or 500 cards. At 1000 cards it was nearly
unbearable. It wasn't until after I left the project that I found that,
had I been navigating by card ID instead of card name, I wouldn't have
noticed much of a slowdown-- if any!
The HyperCard Script Language Guide (version
2.2), mentions this in a single sentence on page 88: "HyperCard can
generally find objects faster if they are identified by ID number."
What it doesn't mention is that the difference only becomes apparent in
large stacks.
Brian Molyneaux, formerly of Heizer software,
provided the explanation for me:
"I can see why the name method was slower.
The file format is linear so an index number (card number) or an id number
(probably located via a hashing table) would be faster than searching all
the objects for a particular name. Card numbers would probably be fastest
after the stack is compacted twice (the first compact purges free space,
the second compact optimizes the objects in the file for fastest access)."
b) Limitations in using a large number of items
For one project I wanted to create an index of all words used in a stack.
I created a handler to go to each card and put every word into consecutive
lines of a variable. I sorted the variable, tossed out duplicate words,
then put the remaining words into yet another global and went on to the
next card. By the time I was done, I had a listing of over 40,000 words.
I then sorted the listing of 40,000 words
and stepped through it, line by line, saving off each new word I came across.
At the beginning, the process was fast. I was checking about 5 words a
second, but by the time I hit the 5,000th word, the time was down to about
1 word a second, and at word 30,000, it had slowed to a crawl.
I wondered: why did it start so fast to begin
with, then slow so dramatically? I can't say for sure, but I suspect when
I was checking word 5,000 against word 5,001, HyperCard had to count the
words before it knew what word 5,000 was, and then had to count again to
find word 5,001. The higher the number, the longer it took to find the
word it wanted.
So I had an idea: I took my 40,000 word list
and grabbed 5,000 word chunks out of it. Then I worked on each chunk of
5,000 individually. Word 35,001 was now word 1 of chunk #8, and was ripping
through the start of this chunk at 5 words a second instead of 5 seconds
per word.
Similar speed improvements can be had if you
are working with large numbers of characters, lines, or whatever. When
HC has to count to a big number to find what you want to work with, you
are probably better off breaking your variable into several pieces. In
fact, I wouldn't be surprised if the optimal size would be to have the
square root of the number of items be both your chunk size and the number
of items to put into the chunk. That is, for a list of 40,000 words, the
optimal chunk would be 200 items in 200 chunks - at least that's my guess.
As an aside: I just (Jan 31, 1997) ran across another instance where this tip came in handy. HyperCard was reading from a huge text file-about 7.5 megs worth-line by line, and sure enough, as it neared the end HyperCard bogged down. So instead of reading the original file line by line, I split it into about 30K chunks and read those line by line. It ran much faster!
Timed examples are presented in the "HyperCard Speed" stack.
5. Smoke and Mirrors
Sometimes you can give the appearance of HyperCard being faster than it really is by using two techniques:
1) Do the visible work first.
2) Provide a progress indicator.
By doing the visible work first, you give the user something to do (a
paragraph to read, a puzzle to solve, a strategy to create), while the
rest of the handler is finishing up. As the saying "a watched pot
never boils" reminds us, making the users sit around with nothing
to do just makes them impatient; give them something to do and they might
not notice the time.
By providing a progress indicator, you give
the user a sense of control over the Macintosh. The user can decide if
he wants to allow the handler to complete or if he should force it to quit.
Timed examples are presented in the "HyperCard Speed" stack.
Download the HyperCard Speed Tips stack. The stack contains this article's text plus a series of timed demos to illustrate these techniques.
E-mail Robert Howe
Robert's web site will moving from [old
site] to [new site]
E-mail HyperCard Heaven about this
article
HyperCard Heaven
http://members.aol.com/hcheaven/
This page was last modified on February 9, 1997