Large databases kaput?

J. Landman Gay jacque at
Sat Jan 3 13:59:04 EST 2009

dunbarx wrote:
> 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 
little data.

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
HyperActive Software           |

More information about the Use-livecode mailing list