Large databases kaput?
J. Landman Gay
jacque at hyperactivesw.com
Sat Jan 3 12:59:04 CST 2009
> Thanks for the reply, but not that. I heard on another thread that there
> was a Rev issue with large stacks, 5000+ cards. I wanted feedback before
> I made a test stack to check it out. Is it a matter of navigation,
> finding stuff, open/close or what?
As Bjoernke mentioned, it's mostly a question of speed. Rev doesn't have
HC's hintbits (and can't; it is proprietary info) and so searches need
to look at every text block to accomplish a find. If your stack doesn't
rely on "find" (or you don't mind waiting) then you can get away with
much larger stacks. If you need to navigate to a particular card
quickly, creating your own index using card IDs is the fastest way to
manage it. Card IDs are faster than any other type of card access.
Rev is entirely RAM-based, so if your stack is tens of megabytes in size
it will take longer to load it all than a smaller stack. If you do not
have enough available RAM to hold the entire contents, speed will also
be affected by the required disk paging to virtual memory.
The 5000 card number is a very gerneric estimate only. A stack with a
single field on each card can remain responsive even with many more
cards than that. If each card has many fields, the number is lower. I've
had stacks with ~8000 cards that worked okay (though a bit sluggishly)
because each card shared a background with only 2 fields containing very
If you have a specific stack in mind, I'd say to convert it and see how
it does. Each one will behave differently depending on the objects on
the cards and how you need to navigate.
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the use-livecode