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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
