Bob Stelloh: FWIW, I have learned that in a repeat
loop, with a large number of cards, it takes longer
and longer to "go to card i" after i goes past about
1000, and 
eventually it can take many seconds to get to the next
card. It does not slow down if you instead "go to next
card" and count separately to get out of the loop. If
you are not doing this, try it, and you will be
pleased by how much faster it goes.

Alain: Here are a few of my suggestions to make
HC-databases faster :

1. Use syntax like "put fld x of card y into var",
instead of going to the card and using the following
syntax: "put fld x into var". Going to a card is much
longer than remotely referring to it.

2. Exploit HyperCard's "dontSearch" property to
eliminate the cards/bkgnds/fields that you never want
to find, thus pruning the search-space.

3. Use HyperCard as the database's shell and GUI, but
store your data externally: (a) as structured text
files, or (b) in a 'real' database format, like dbm
for example. 

4. For the latter, I bridge HyperCard and the dbm
database(s) with MacPerl, because (OSA-compliant)
MacPerl is currently supported by HyperCard! You can
set the scripting-language of a script to "perl", or
have HyperCard itself DO it: "do someScriptVar as
perl".

5. This same 'perl' trick can be used to make
HyperCard do anything that MacPerl can do, like
pattern-matching for example. If you thought that
HyperCard's chunking abilities are (natively)
powerful, then you are in for a pleasant surprise if
you adopt this suggestion.

6. This same 'perl' trick can also be done, of course,
with AppleScript: "do someScriptVar as applescript".
Which allows you to make HyperCard do anything that
AppleScript can do, including the ability to tell
other scriptable applications (like FileMaker, for
example) to do stuff.

7. Even the text-files approach is viable.
Surprisingly fast in HC, albeit somewhat inefficient
in terms of disk-space-usage, particularly since
volumes are in the giga-bytes range these days. Think
HFS+ and you will grasp what I am getting at. With the
text-files approach, you are in effect using the
Finder as a database. Not as efficient as a 'real'
database, but much more versatile and accessible. With
Sherlock full-text indexing, we now have indexing as
well! And the fact that the Finder is scriptable and
recordable makes this approach all the more interesting.
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Reply via email to