use-revolution Digest, Vol 82, Issue 5
gregory.lypny at videotron.ca
Fri Jul 2 13:30:10 CDT 2010
Good stuff, Richard. Thank you for these insights.
On Fri, Jul 2, 2010, at 1:00 PM, Richard Gaskin wrote:
> Message: 7
> Date: Fri, 02 Jul 2010 07:33:23 -0700
> From: Richard Gaskin <ambassador at fourthworld.com>
> Subject: Re: Saving Changes in a Standalone
> To: How to use Revolution <use-revolution at lists.runrev.com>
> Message-ID: <4C2DF8B3.8080006 at fourthworld.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> stephen barncard wrote:
>> Remember a stack can both be a visible window with objects and
>> a holder for scripts, it can also be a very efficient and
>> addressable data container.
>> The stack one compiles as an app can call other stacks that are not
>> compiled. The best of both worlds.
> Stack files are my favorite means of storage. These days I only use
> text files for ultra-large repositories too big to be loaded into RAM
> (with an index you'd be surprised how fast Rev can get in and out of
> such things with seek). But for almost everything else I use stacks.
> With stacks you can use custom props, which are by far the most
> efficient means of using persistent arrays in Rev. RevTalk provides the
> arrayEncode and arrayDecode functions which can be used for similar
> purposes, but the overhead of translating arrays with those functions is
> many times more costly than just opening a stack which has the data in
> custom props.
> I've tested with more than 100,000 custom props on stack files up to
> 100MB, and as long as you have the RAM it works great. Smaller files
> (50MB or less) work amazingly fast in most memory configurations, even
> with similarly large numbers of props.
> Since custom props can be separated into property sets, you get two
> levels of hierarchy supported with amazingly efficient access speed.
> While it's possible to store arrays in props to extend that hierarchy
> further, the speed is lost as those need to go through the internal
> equivalent of arrayDecode to be accessed.
> But as long as you stick with property sets and properties you get a
> robust data store that's hard to beat for efficiency. If you need a
> deeper hierarchy you can add objects there and use those props as well.
> That's one of the other things I like about stack files as data
> stores: you can store either text or binary data, or even native
> objects, mixing and matching for nearly every need.
> Extra bonus points: unlike a text file, with stacks you get an
> automatic backup made during save, so if you have a power outage or
> other interruption during save at least you'll have a copy of your last
> saved file, found in the same directory with the same name preceded with
> Tip: The engine currently doesn't prevent you from using property names
> longer than 255 chars, but as noted in the Limits section of the docs
> such names are not allowed. If you attempt to use a longer name it will
> corrupt your stack file - see:
> Just stick to the 255-char limit and you're good to go. Short strings
> and of course numeric keys work great.
> Richard Gaskin
> Fourth World
> Rev training and consulting: http://www.fourthworld.com
> Webzine for Rev developers: http://www.revjournal.com
> revJournal blog: http://revjournal.com/blog.irv
More information about the use-livecode