Keys of a custom property array

[Peter Haworth]

Richard,
I think your explanation of how arrays stored in cprops are translated back
and forth between internal and external storage explains the the
performance differences in Mark's tests.

I am curious though about your comment on storing multi-dimensional arrays
in cProps.  Are you saying it's not possible to store multi-dimensaional
arrays in cProps?  I was hoping to do that in a project I'm about to start
on.


Pete
lcSQL Software <http://www.lcsql.com>


On Sun, Mar 3, 2013 at 5:27 PM, Richard Gaskin
<ambassador at fourthworld.com>wrote:

> It seems there are two types of arrays storable in LC props, what I like
> to call "Natural" and "Unnatural":
>
> "Natural" arrays are one-dimensional, and fit into the traditional view of
> custom props as having one or more property sets, each of which is
> comprised of properties, each of which has a key and a value.
>
> "Unnatural" arrays are what you have when you story any array into a
> custom property value.  I haven't fully tested this theory out, but it
> seems to be that when you store an array into a custom property the engine
> first runs it through arrayEncode, and to access it uses arrayDecode, both
> of which are notoriously slow operations since they require iterating
> through the complete structure to translate it from the
> RAM-address-optimized version of the array in memory and it's simpler
> linear structure for storage.
>
> The difference between the two is why some of the array syntax like "get
> myArray[key1][key2]" can't be used with arrays stored in custom props,
> because in actuality the custom property is only one level deep, and
> anything deeper is emulated through arrayEncode/arrayDecode.
>
> Given this, though I don't have my benchmarks with me at the moment, I
> believe that if you can fit the data you need into the "natural" array
> storage of custom properties and property sets, and use "the customkeys" to
> access those directly from the object record, you should see the most
> minimal impact on both execution time and memory space.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for Desktop, Mobile, and Web
>  ______________________________**______________________________
>  Ambassador at FourthWorld.com        http://www.FourthWorld.com
>
>
>
> ______________________________**_________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/**mailman/listinfo/use-livecode<http://lists.runrev.com/mailman/listinfo/use-livecode>
>