global variables vs. custom properties
ambassador at fourthworld.com
Fri Jan 16 10:34:39 CST 2009
Tiemo Hollmann wrote:
> I know, that similar topics has been discussed a few time, but didn't found
> any hard facts
> It is the usage of global variables vs. custom properties for non persistant
> values, used at different parts within the app.
> I know, that most people prefer custom properties, but is it just a question
> of "school", or is there perhaps a difference in memory usage or other "hard
The others here have covered the differences well, and all I could add
is a note about style and efficiency.
For myself, it feels most natural to use properties as instance
variables for objects; since they are bound to objects, I tend to use
them for object-specific data.
And since they can be stored in a stack file, they're also useful for
general data like preferences or documents since it's easy to save the
stack file as we would any other data file.
What I dislike about using properties for general data is having to
remember where they are, and to include the object specifier in the
put the uProp of btn 1 of stack "MyData" into tVar
With globals it seems a bit more fluid to just write:
put gValue into tVar
But of course globals require a declaration, which can be made once for
an entire script so it's only one more line, but it's still one more line.
So for some things I make accessor functions:
put MyValue() into tVar
...where MyValue is a function somewhere in the message path that
figures out for me where the data is and returns it.
Accessors give me the option of changing how and where data is stored at
any time without having to modify any scripts that use them, and I don't
need to type the object specifiers as with properties or the declaration
as with globals.
But the convenience of accessor functions come at a small price in
I wrote the benchmarking script below some years ago to measure the
relative performance of globals, properties, and functions for obtaining
values, and have run it against most engine versions released since with
fairly consistent results:
-- In button:
set the cTest of me to 100
put 100 into gTest
put 1000000 into tTimes
put the milliseconds into tStart
put "Global: "&the (milliseconds - tStart)/tTimes into tOut
put the milliseconds into tStart
get the uTest of me
put cr &"Property: "& ( the milliseconds - tStart)/tTimes after tOut
put the millisecs into tStart
put cr & "Function: "&( the milliseconds - tStart)/tTimes after tOut
-- in card:
For computationally intensive operations, the benefits of globals are
But note that the times shown are in milliseconds per iteration, so
while there is a relative benefit to using globals over properties or
functions, the benefit is so small that it makes little difference for
As much as I like to keep an eye on performance when designing an
application's internal API, I have to balance runtime performance with
development efficiency, making decisions on a case-by-case basis as to
which will deliver the most benefit overall.
In a repeat loop processing lots of data I'll usually choose the fastest
method, willing to add a few comments to clarify anything that may not
But for things that happen in response to user actions (selecting a menu
item, clicking a button, etc.), the user is so much slower than the
computer that I can safely afford to take liberties with a few fractions
of a millisecond if it makes my work in delivering the feature that much
simpler to write and maintain.
Revolution training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
More information about the use-livecode