Best Practices using globals vs. custprops?

[Richard Gaskin]

Tiemo wrote:
> on various sites - and again in this best practice thread - it is
> recommended not to use globals, or at least so less as possible, because
> they can be changed from everywhere and that's hard to debug and no nice
> style. I really don't see any difference between using globals or properties
> yet. Properties can be changed also "from everywhere" and even if you write
> a central handler to change your properties, this handler can be called from
> everywhere. What is the best practice for statuses, flags and all these
> global informations, you need at different times and in different handlers?
> And if there is a "clean pratice", what is the difference to using globals?

There was a very enthusiastic discussion about this not long ago -- my 
contribution to it is here:

<http://lists.runrev.com/pipermail/use-revolution/2007-March/096113.html>

I think the others here have addressed the most salient points, so the 
only thing I might add is the gentle reminder that maybe the best 
mnemonic device for knowing when to use a global variable is its name: 
if you need data to be accessed globally, it can be a good choice.  And 
if you need to associate data with a specific object, or need 
persistence, custom properties can be a good choice.

As far as speed, whenever you can avoid the overhead of requiring the 
engine to parse an object's data structures you'll likely save time. 
The overhead is most dramatic with storing data in fields, where the 
data structures are among the most complex in the engine.  Getting a 
global can be several times faster than getting the same data from a 
field, and measurably faster than getting it from a custom property.

That said, it's worth noting that the time per access is pretty short 
either way, so performance is only really an issue for data that's 
accessed in a large number of iterations.

Here's a simple benchmark to measure this:

1. Make a stack with one button

2. Put this script in the button:

global gTest
on mouseUp
   set the uTest of me to 100
   put 100 into gTest
   put 100000 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

3. Put this script in the card:

function FooTest
   return 100
end FooTest


4. Click the button.


The results I get here on my MacBook Pro 2.16GHz are:

Global:   0.00021
Property: 0.00122
Function: 0.00082


Note that those times are in milliseconds per access; unless you're 
accessing the data frequently, it probably won't amount to any 
noticeable difference no matter which method you use.

This experiment also introduces a third option to the discussion:  using 
functions for values that are used as read-only.

Functions have these benefits:

- They're faster than property accesses

- They don't require a declaration in each handler that uses them

- They carry no risk that something in these calling handlers might muck 
with the data

- They can be defined and maintained in a shared library for easy reuse


-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com