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
facts"?
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
access call:
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
performance.
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:
BENCHMARK SCRIPTS:
-- In button:
global gTest
on mouseUp
set the cTest of me to 100
put 100 into gTest
put 1000000 into tTimes
--
-- Global:
put the milliseconds into tStart
repeat tTimes
get gTest
end repeat
put "Global: "&the (milliseconds - tStart)/tTimes into tOut
--
-- Property:
put the milliseconds into tStart
repeat tTimes
get the uTest of me
end repeat
put cr &"Property: "& ( the milliseconds - tStart)/tTimes after tOut
--
-- Function:
put the millisecs into tStart
repeat tTimes
get FooTest()
end repeat
put cr & "Function: "&( the milliseconds - tStart)/tTimes after tOut
--
put tOut
end mouseUp
-- in card:
function FooTest
return 100
end FooTest
RESULTS:
Global: 0.00023
Property: 0.00151
Function: 0.00198
For computationally intensive operations, the benefits of globals are
clear.
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
most operations.
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
be self-evident.
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.
--
Richard Gaskin
Fourth World
Revolution training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
