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
_______________________________________________
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

Reply via email to