Overhead referencing an object

[jmk_phd]

I can pretty much guess forum members' advice: namely, that I should mangage more scrupulously the defaultstack property when an external stack used to store client-entered data is opened invisibly by the main stack. (Mea culpa.)

Still, I'm curious -- if anyone knows -- to what extent explicitly detailed references to an object impact the size and/or efficiency of a standalone application.

For example, consider the snippet, intended to modify the main stack (C) while the external stack is still open:

repeat with x = 1 to the number of buttons in group "A" of card "B" of stack "C"
set the hilite of button x of group "A" of card "B" of stack "C" to false
end repeat

When LiveCode does its magic in converting to a standalone, do the explicit references to card and stack bloat the size of the standalone, or does LiveCode encode these just as efficiently as if defaultstack had been employed?

Obviously, such explicitly detailed references require more typing -- although, as a trade-off, the specified object is thereby easier to identify when reviewing the code.

Thanks much.

jeff k

[dunbarx]

Hi.

Not quite sure what your concern is. Memory? Speed?

The executable (the "splash" stack) contains a stripped-down copy of the essentials of the LC engine. There is little you can do to that or about that except to make sure that unneeded inclusions are, er, not included.

Beyond that, any attached stack files are intended simply to cater to your needs. Inter-stack navigation, remote object references, whatever, are all standard practice, and I would never worry at all about overhead in their use. And I certainly would not try to minimize the number of attached stacks or substacks, or worry overmuch about streamlining code to minimize their use or their interactivity.

Craig Newman

[Klaus]

Hi Jeff,

it is just TEXT!

10000 lines of the string -> of group "A" of card "B" of stack "C"
results in a 350 KB text file.

Now you judge if this "overhead" will make a difference and remember that LC will load a complete stack
including substacks into memory, so access times are NANOseconds.


Best

Klaus

[jacque]

The defaultstack function was added specifically to reduce the amount of typing the scripter needs to do, but the engine has to do more work under the hood. Every time an incomplete reference is used, the engine has to look up the defaultstack. If a defaultstack isn't set, it then has to determine which stack is the topstack. So an incomplete reference adds a tiny bit of overhead to every call. It's minimal and barely registers, but complete object references will be marginally faster.

The tradeoff is cluttered code. I don't use complete references when the topstack or the defaultstack is clear. I do use them when there may be confusion about the target stack. The engine is pretty good about telling you when it can't construct a complete stack reference.

[jmk_phd]

Thanks to all who addressed my inquiry!

Although I'd composed a detailed acknowledgment of each of your replies, my message was -- for some frustrating reason -- just lost when I clicked the "Submit" button. Sorry.

Bottom line is that I appreciate all of your replies and that the overhead associated with employing complete object references is not a significant issue with respect to memory, speed of execution, or standalone file size.

jeff k

[FourthWorld]

...complete object references will be marginally faster.

Interesting. It wouldn't have occurred to me that different object reference resolution methods could make much of a difference, but indeed they do.

I ran a quick test comparing the explicit form shown in the OP with a shorter form easier to type ("btn x of grp tGrpobj", where the tGrpObj contains the long id of the group). Running those on 100 objects in the group 100 times in each test, there a difference of more than 2.5 times:

0.0135 ms per iteration for explicit form
0.0363 ms per iteration for more condensed form

A difference of a few microseconds per object probably won't matter much for most cases, but good to know if one has to iterate over a very large number of objects.

Were you ever able to figure out how to script to take advantage of the "ID caching" added a few versions back? I read that description several times, and still can't figure out how to make use of it.

[jacque]

I'd forgotten about ID caching so I haven't done anything with it. In fact, I don't even remember what the description said. I wouldn't mind looking at it if I knew where the original reference was.

[FourthWorld]

I dug up an old list thread about it. Ignore my sloppy paste there, the relevant part is:

The engine now caches lookups of control references of the form
“card id ...” and “control id ...”.
This speeds up any access using those forms after the first time,
turning an operation that would be completed in linear time into
one that will be completed in constant time.

http://www.mail-archive.com/use-livecod ... 38638.html

[jacque]

Thanks, I read the thread and saw that I'd not only replied, but you did too, and Alex Tweedly did the benchmarking:
http://www.mail-archive.com/use-livecod ... 38720.html

It was a long time ago and because it was internal to the engine and already tested, I've just ignored it and enjoyed any speed increase that may occur. It just kind of faded into "things the engine does to make life easier for me."

[FourthWorld]

I remember seeing Alex' post, and maybe I just need his sample stack because when I try to reproduce his results I get roughly equivalent times for both methods.