Stack Level Local/Globals
Dennis Brown
see3d at writeme.com
Mon Jul 4 17:42:07 EDT 2005
On Jul 4, 2005, at 3:07 PM, Eric Chatonet wrote:
> Hi Dennis,
>
> I agree since I provide many tools for the community that are made
> to run in the IDE.
> So I never use globals but I prefer to refer to some custom
> properties stored in specific custom property sets in my plugins or
> in the revPreferences stack.
> BTW, I found that referring to custom properties is as fast as
> using global variables and they don't vanish when they are stored
> in revPreferences.
> That's great :-)
Eric,
This sounded like good news, so I ran a test to see how fast a global
vs custom property set would run. I used the following script (the
first time through is many times slower as the array elements need to
be created, so the timings are separate for the first or the average
of the next times):
------------------
[snip]
REPEAT 1000 times --change to 100 for second example, and 10 for
third example
put "A nice line to repeat"&cr after stuff
END repeat
put the long seconds into strt
REPEAT with y=1 to 100 --Y values, change to 1000 for second
example
REPEAT with x=1 to 100 --X values, change to 1000 for third
example
--
put stuff into stuffArrayG[x,y] --use this line for
global time test
--
set the stuffArrayP[x&&y] of this stack to stuff --use
this line for custom property time test
--
END repeat
END repeat
put the long seconds - strt
------------------
The timings for the first test of 10,000 elements:
10,000 Custom Property Set Array: First: 5 sec, Next: 0.5 sec
10,000 Global Array: First: 15 sec, Next: 0.3 sec
So this is very surprising. Global arrays require three times as
much time to create an element as a Custom Property Set array.
However, the global arrays are almost twice as fast for repeated
stores to an element that already exists.
------------------
However, when I change the REPEAT 1000 times to REPEAT 100 times and
change with y=1 to 100 to with y=1 to 1000, I get the following times
for 100,000 elements but same amount of data:
100,000 Custom Property Set Array: First: 3.5 sec, Next: 2.3 sec
100,000 Global Array: First: 1.2 sec, Next: 1.0 sec
Now it appears that the globals are about 2.5 as fast as the custom
properties.
------------------
Now, when I change the REPEAT 1000 times to REPEAT 100 times and
change with y=1 to 100 to with y=1 to 1000, I get the following times
for 1,000,000 elements but still the same amount of data:
1,000,000 Custom Property Set Array: First: 25 sec, Next: 25 sec
1,000,000 Global Array: First: 11 sec, Next: 10.5 sec
Now it appears that the globals stay about 2.5 times as fast as the
custom properties.
Changing the script to time the read operation gives:
1,000,000 Custom Property Set Array: 27 sec
1,000,000 Global Array: 8.7 sec
------------------
The conclusions are a bit hard to understand for this example, but it
appears that custom properties sets used instead of global arrays are
about 2.5 times as slow for writing and 3 times as slow for reading,
except for the case where a very large data string is stored, then it
seems to take much longer for the globals to create a very large data
space for each element. I can only conclude that the method used for
creating new data space for globals involves a lot of shuffling of
memory structures, while the method used for custom properties is
simpler. However, it is only a guess at this point.
In any case using custom properties for the compute intensive arrays
would significantly slow my program. However, they would be a viable
alternative to globals for many cases.
> But...
> The main aim with Rev is to build standalones where this problem
> does not exist since all yours globals are of course stack global
> variables ;-)
I would agree, except that with the DreamCard product, It is now
practical for a user to run everything in the IDE --which is what I
do. The only reason that I would want want to make a stand alone
(which can not be done with DreamCard anyway) is so that I could run
more than one application at the same time in different OS "threads".
Dennis
More information about the use-livecode
mailing list