Scott Kane wrote:
I'd be curious to know why RR decided to change the behaviour of how stacks are read (from file as opposed to loaded fully into RAM).
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.
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.
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.
-- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com _______________________________________________ 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
