use-revolution Digest, Vol 82, Issue 5

[Gregory Lypny]

Good stuff, Richard.  Thank you for these insights.

Gregory

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:
> <http://quality.runrev.com/qacenter/show_bug.cgi?id=8840>
> 
> 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