David Bovill wrote:
2009/9/26 Richard Gaskin <ambassador at fourthworld.com>
Is there any trick to using customProperties[<arrayNotation> to access
nested array elements in an object?
No. As far as I understand it the new nested array data structure uses
arrayencode / arraydecode internally and this adds the speed hit.
That's what it seems, and arrayDecode/arrayDecode benchmark as the
slowest of all array storage options I've found.
Oddly enough, two-dimensional arrays (property set + property list) work
reliably and lightning fast, e.g.:
put the uPropSet[tSomeProp] into tResult
But alas attempting to go deeper fails:
put the uPropSet[tSomeDeeperKey][tSomeProp]
:(
For that reason, and others I've moved over to using getprop / setprops
together with script locals to store nested arrays. These are then loaded
I think when the stack (or card / object) is loaded so you get the speed
increases and the same syntax.
I've used getProp and setProp in a number of projects, and they do make
convenient accessor for some uses (though I still prefer simple commands
and functions for many accessors as they require less typing, using
getProp and setProp for cases where the storage object may change).
But in this project the data will be loaded and accessed only once in a
given session, so it would be ideal if we could have both persistence
and efficient performance.
Looking into the RQCC this morning I found an excellent discussion on
this by Mark Waddingham in in request submitted by Björnke:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=6912>
The solutions Mark offers there would be great - easy to read, easy to
write. If only they existed. ;) I added a few votes in hope that they
one day will. Good ideas there.
While I was there I added a request to solve the bloat problem with keys
of sub-arrays within a parent array in which all of the sub-arrays use
the same key names:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=8304>
--
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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
