Custom Properties versus Arrays

Got a LiveCode personal license? Are you a beginner, hobbyist or educator that's new to LiveCode? This forum is the place to go for help getting started. Welcome!

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller

Post Reply
richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 4346
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Custom Properties versus Arrays

Post by richmond62 » Fri Feb 22, 2019 11:21 am

Someone expressed surprise yesterday that I managed my whole Devawriter Pro without
using any arrays.

I was surprised that anyone would think that necessary.

HOWEVER, lying in my bath (not waiting for Charlotte Corday to turn up) and thinking, I began to think
about storing data in readily accessible places . . .

Now to put data into arrays (as far as I understand things) means that every time a stack/standalone
starts up a fairly long and time-consuming routine has to run to "pack" all the data into these arrays

(of course I could be quite wrong in this respect, but why do I have the feeling that arrays "die" once
a stack/standalone is shut down?)

so why not 'pack' all the data into custom properties of an object ONCE and then it will be there
whenever it is needed?

ClipArtGuy
Posts: 226
Joined: Wed Aug 19, 2015 4:29 pm

Re: Custom Properties versus Arrays

Post by ClipArtGuy » Fri Feb 22, 2019 11:48 am

richmond62 wrote:
Fri Feb 22, 2019 11:21 am

(of course I could be quite wrong in this respect, but why do I have the feeling that arrays "die" once
a stack/standalone is shut down?)

Something like DevaWriter is a bit out of my league BUT, you can store an array in a custom property, which may or may not be useful for your needs.

bogs
Posts: 4608
Joined: Sat Feb 25, 2017 10:45 pm

Re: Custom Properties versus Arrays

Post by bogs » Fri Feb 22, 2019 1:14 pm

Hm. An array is just a formatted set of key value pairs. A custom property can be any thing, really, as far as my understanding on it goes, but in its simplest form it can be a storage container which, as ClipArtGuy said could hold an array.

Using an array isn't a necessity, per se, but it is better for some purposes than a regular variable.
richmond62 wrote:
Fri Feb 22, 2019 11:21 am
Now to put data into arrays (as far as I understand things) means that every time a stack/standalone
starts up a fairly long and time-consuming routine has to run to "pack" all the data into these arrays
That long and time consuming part is off, it wouldn't likely take much longer than a millisecond or two, depending on how you put the information into it. It would be longer and more time consuming to decide what you need in it though, and how to format it.
richmond62 wrote:
Fri Feb 22, 2019 11:21 am
so why not 'pack' all the data into custom properties of an object ONCE and then it will be there
whenever it is needed?
Well, it would be easier to change the way one array is constructed than chase down say, 20 custom properties, for instance :wink:
Image

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6609
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Custom Properties versus Arrays

Post by dunbarx » Fri Feb 22, 2019 2:41 pm

An array is just a variable, just like any other, but with the form Bogs mentioned, and will not survive sessions.

The discussion is on two different tracks, one about storing data and one about the type of data being stored. Two very different tracks.

I like custom properties, though fields would do, since both of these, er, survive sessions.

Craig
Last edited by dunbarx on Fri Feb 22, 2019 4:42 pm, edited 1 time in total.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7640
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Custom Properties versus Arrays

Post by FourthWorld » Fri Feb 22, 2019 4:14 pm

What is the total number of elements the array would contain?
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6609
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Custom Properties versus Arrays

Post by dunbarx » Fri Feb 22, 2019 4:50 pm

I did not do any exhausting testing, but made a simple stack with a custom property holding an array of random data of 100,000 keys.

I did not see any difference in opening time when starting LC from that stack as opposed to any other stack. I assume that a custom property holding a megaByte or so of ordinary data in a custom property would behave similarly.

@Richmond.

What was the basis of your "packing" thing?

@ Richard.

You would know. Anything unusual about how arrays are stored, whether in a custom property or as a live variable?

Craig

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7640
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Custom Properties versus Arrays

Post by FourthWorld » Fri Feb 22, 2019 6:18 pm

dunbarx wrote:
Fri Feb 22, 2019 4:50 pm
@ Richard.

You would know. Anything unusual about how arrays are stored, whether in a custom property or as a live variable?
Lots, but probably more than anyone wants to read, and most of it not relevant to this thread.

For the moment let's explore the use-case at hand. Once Richmond gives us an idea about the scope of the data we can help guide solutions toward a good balance of developer convenience and runtime efficiency.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 4346
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Custom Properties versus Arrays

Post by richmond62 » Fri Feb 22, 2019 7:56 pm

Once Richmond gives us an idea about the scope of the data
You are expecting too much I'm afraid.

I was lying in my bath having a good, hot, long soak at the end of a bad, cold, long day, and
musing on someone's comments about my not having employed arrays in my Devawriter program.

While I am just starting a fairly radical refactor of my Devawriter, I have NO intention of using
arrays at all.

The question that bubbled up in my mind (probably more interesting than the other things
that bubbled up in the bath) was a question of efficiency, and purely as a theoretical idea.

Let me restate it in a way that, I hope, is a bit clearer:

I could have a dataset consisting of many thousands of items (e.g. names, ages, genders,
addresses of all the people in a small, mid-western tone - let's say Carbondale, Illinois)
that I wish to access and "play around with" in a stack/standalone.

Now, at startup I can envisage 2 possibilities:

1. I have an openStack script that takes all of the data in my dataset and enters it into
an array (that's is what I mean by pack).

2. I have a stack that has the dataset already stored as one or many custom properties
in an object inwith that stack (having entered the dataset once when making the stack).

It would seem logical (?) that choice #2 is more economical in terms of the fact
that the stack does not run through an "array packing" script every time it starts up:
this could involve quite some time at startup.

Of course the custom property could consist of an array.

The point is that that array would only have to be entered
once into a custom property because a custom property is not volatile.

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6609
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Custom Properties versus Arrays

Post by dunbarx » Fri Feb 22, 2019 9:21 pm

Richmond.

Ah, so you mean that the stack would read data from an external file and then store that data for future use inside the stack itself. That is what might take some time. I am not sure how onerous that might be, though I suspect not too much.

We maintain several external text files on a server so that multiple users, each using their own instance of a standalone, can access a common dataset for local processing. The remote datasets are updated regularly based on activity derived from those standAlones, so that they are always "current".

Obviously, I am using such methods in a crude, hobby-like and non-grown-up manner. I have never had a discussion with a real database-oriented LC'er, to see what they do, in the most basic way, as a matter of course.

But apart from our multi-access requirement, I see no reason not to store data within the stack itself. That has always seemed more compact and manageable, and I do that always.

Craig

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7640
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Custom Properties versus Arrays

Post by FourthWorld » Fri Feb 22, 2019 10:16 pm

Optimization depends on particulars. If there are no particulars, no best answer is possible.

Also, when considering performance, it's often helpful to think in real-world terms rather than just measurements. For example, if you spend four days implementing something that saves you four milliseconds, what you have is indeed faster but at an undesirable cost.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6609
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Custom Properties versus Arrays

Post by dunbarx » Fri Feb 22, 2019 10:49 pm

Every millisecond is sacred.

Craig

bogs
Posts: 4608
Joined: Sat Feb 25, 2017 10:45 pm

Re: Custom Properties versus Arrays

Post by bogs » Fri Feb 22, 2019 11:09 pm

richmond62 wrote:
Fri Feb 22, 2019 7:56 pm
Once Richmond gives us an idea about the scope of the data
I could have a dataset consisting of many thousands of items (e.g. names, ages, genders, and addresses of all the people in a small, mid-western town - let's say Carbondale, Illinois)
that I wish to access and "play around with" in a stack/standalone.

Now, at startup I can envisage 2 possibilities:

1. I have an openStack script that takes all of the data in my dataset and enters it into
an array (that's is what I mean by pack).

2. I have a stack that has the dataset already stored as one or many custom properties
in an object inwith that stack (having entered the dataset once when making the stack).

It would seem logical (?) that choice #2 is more economical in terms of the fact
that the stack does not run through an "array packing" script every time it starts up:
this could involve quite some time at startup.
<sic>
The point is that that array would only have to be entered
once into a custom property because a custom property is not volatile.
In the example as you put it, I would actually think the array would be the more efficient of the 2 choices, short of using a db.

For one thing, you are talking about a population dataset. Population datasets change constantly, people move in, people move out, people are born, people die. This isn't a steady state situation, where the information never changes.

Also, as far as survivability of the information goes , once the code is written to pull in what you want, it is for all intents and purposes *done* (to the limit code is ever *done*), and the information (barring source or format changes) will be pulled in and sorted reliably there-after. If the source or format *does* change at some point, your talking about minimal coding to correct for that in most cases.

Looking at putting it into a custom property, though, how would you do it? Copy and paste it manually? The information changes, it requires doing it again (and possibly repeatedly).

Code it to automatically be put into the custom property? That is about the only way I see this going where it again becomes a trade off, but the array, being written at the time of starting the program each time, skips having to check the data as you would have to check for changes in the custom property.

Not only that, but you'd have to use the splash stack setup so that the custom property could be re-written each time. I use it myself a lot, but with an array you wouldn't be forced to.

Unless the dataset is static, such as a list or value that never changes, then it would seem that you would almost certainly be better off coding it into an array than putting it into a custom property, unless you need global access to it, but as you point out you could just stick the array in a custom property and be back to a wash on which is better.

The other thing I notice about this question is that it resembles the question of whether an if/then or case/switch statement is better for problem xyz. I don't know about how this language handles one vs. the other, but in some of the other languages I've used, the difference between the two was that every if/then is evaluated, where as case/switch is only evaluated for the one true instance.

Your question makes me curious how Lc evaluates the two :D

Of course, I doubt any of this would apply to your particular program (Devawriter), but I could be wrong. Just my POV.
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7640
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Custom Properties versus Arrays

Post by FourthWorld » Fri Feb 22, 2019 11:33 pm

bogs wrote:
Fri Feb 22, 2019 11:09 pm
In the example as you put it, I would actually think the array would be the more efficient of the 2 choices, short of using a db.
Possibly. Sometimes flat files are faster than SQLite for simple retrieval operations.

The world has so many different storage options because so many different factors come into play with such choices. There is no one-size-fits-all.

Everything depends on particulars, and without particulars no optimal recommendation is possible.

And many times speed alone is not the best measure of fitness for a particular storage option. Development time, long-term extensibility/flexibility, and many other factors come into play with such choices.
The other thing I notice about this question is that it resembles the question of whether an if/then or case/switch statement is better for problem xyz. I don't know about how this language handles one vs. the other, but in some of the other languages I've used, the difference between the two was that every if/then is evaluated, where as case/switch is only evaluated for the one true instance.

Your question makes me curious how Lc evaluates the two :D
My understanding is that case statements stop evaluating at the first match, and multi-condition ifs stop evaluating at the first false expression (e.g. given "if 1=2 and 3=3", the "3=3" part will never be bothered with because the first expression evaluates to false).

When choosing between case blocks and nested ifs, that's definitely a very strong case for picking the one which best fits the algorithm itself, rather than contorting the algorithm to fit a performance measurement. Even if you could find an instance where one is faster than another, the difference will be minor, and extremely minor compared to the impact on overall feature deployment from zealously "optimized" spaghetti code.

I often use "repeat with i =..." even though I know "repeat for each..." is much faster, when I know the size of the data will not make the choice prohibitive and it keeps the code clearer.

Though it's out of context, Donald Knuth is often cited as saying "Premature optimization is the root of all evil." Write for clarity first, and when a given operation is a bottleneck go back and revisit to see if it can be optimized. Prioritizing clarity first will allow more features per work-hour, and in many cases any performance difference will not be as noticed by end-users as missing features.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

bogs
Posts: 4608
Joined: Sat Feb 25, 2017 10:45 pm

Re: Custom Properties versus Arrays

Post by bogs » Fri Feb 22, 2019 11:48 pm

Makes sense, and thank you for the explanation on if/then/case/switch.
Image

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 4346
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Custom Properties versus Arrays

Post by richmond62 » Sat Feb 23, 2019 10:59 am

I doubt any of this would apply to your particular program (Devawriter), but I could be wrong.
Have a "warm, fuzzy" on me: you're completely right. 8)

However, odd as this may seem, I do not live, eat, breath and defecate Devawriter; I am also
among other things: an EFL teacher, a husband, a father, and a bathtime philosopher.

So when someone "tickles my grey cells" re arrays I got caught up in an elaborate
daydream about whether they were (especially in the context of LiveCode) all that
they are cracked up to be.

Unlike some folk round these parts I am interested in deploying software on machines
that were made 15-20 years ago (I have some of those, merrily chuntering away with Linux,
in my school); so I have to think about the same sort of thing as when I program on my
BBC Model B with its 32K RAM.

And one would suppose, programming for handheld devices the same considerations would come into play.

----

I don't know why, but when I read this:
"Premature optimization is the root of all evil."
I went off on another tangent about the Catholic church.

Post Reply

Return to “Getting Started with LiveCode - Complete Beginners”