From: "J. Landman Gay" <[EMAIL PROTECTED]>
They didn't; the engine has always worked that way since its original
MetaCard incarnation. Scott Raney, the creator, wanted speed and so wrote
the engine to load everything into RAM. The trade-off is that you need as
much RAM as the size of your stack -- which is one reason why a dedicated
database is more suitable for huge data sets.
Ah - I see. Got it.
Raney's standard suggestion was that databases larger than 5,000 cards
should be moved to a "real" external database. Stacks under that number
perform acceptably well. I have pushed it to 10,000 or so without any
particular indexing or special efforts, but it does slow down, especially
if you use the "find" command to locate content. HyperCard had its
wickedly fast "hint bits" search that Rev doesn't have. When Rev searches,
it has to look through the text of every field which is much slower.
However, if you create an index and the scripts reference cards by ID (the
fastest way) you can increase the number of cards without too much lag.
Interesting.
I wrote a database with over 40,000 records, and for that one I loaded a
text file into RAM and then used a 1-card display stack to show the
desired record. This method requires that you write all your own
navigation and search handlers, but it was about as fast as HC when I was
done.
Was this on a Windows box though? My experience with large text files on
Windows has been that it can really choke. IIRC this is different under
*nix style OS'.
Scott Kane
CD Too - Voice Overs Artist & Original Game and Royalty Free Multi-Media
Music
"When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that something is
impossible, he is very probably wrong."
Arthur C Clarke
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
