global variables vs. custom properties

[Richard Gaskin]

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