Flash 5 ActionScript speed measured

Flash 5 ActionScript Speed Measured.variable And Properties Control

Sometime ago, while I was doing a Flash 4-based GUI project, I opened it on Flash 5 and started finishing the code there. I started to convert all old-style action script code (using slash syntax, getproperty and setproperty commands, etc) to the new-style, dot (object-based) action script syntax. To quote Flash 5 Action Script reference,
You can use dot syntax to get and set the properties and methods of an object,
including movie clip instances and variables. You can use dot syntax instead of
the slash syntax used in Flash 4. Slash syntax is no longer preferred, but it is
still supported by the Flash Player.
So I re-coded my big routines and tested it. To my surprise, the code (that is very processor-intensive) started running slower than before, and I decided to investigate what was going on. After some initial, very surprising results, I decided to run a extensive test on the subject, and measure the difference between the execution time of the "old" and "new" action script coding style. These are my results.

This is not a comparison between Flash 4 and Flash 5, or the speed of these plugins. This is a comparison of "identical" commands running on the Flash 5 plugin: a comparison between the "old style" coding, and the "new style". Setting a variable on Flash 5 using dot syntax and slash syntax should be the same, and run at the same speed, isn't it? Well, this is not quite the case. Read on.

1. Method

The mission was simple: to run some kind of command using the "old" flash-4 style syntax, and then run the same command using the "new" flash 5, recommended style. Like benchmarks like this kind are done on other languages, the best way was to execute the functions several times, measure its running time, and then compare the two results.

I have then created a small, fast and simple .FLA file on Flash 5, that would run several commands and measure its running time. Here's the script I have used:
i = 0;
t = getTimer ();
while (i < lupis) {
   <<command to test here>>
   i++;
}
result = getTimer () - t;
So, it would run the same command several times (the number expressed in the lupis variable; I used 60000, meaning 60000 executions of each command, for my tests) and then return the result measured in miliseconds. By doing this several times, each time with one command, I was able to measure the running time of each command compared to its equivalent, and then determine which one was faster. The results didn't stop to surprise me, as you will see soon.

It's important to note that while the loop used to measure the script can't have many flaws, the way it is executed (before/after other commands, etc) could modify the result. Because of this, I ran the scripts each one in a separated frame, without any other thing going on on the movie at the same time, and I have even swap the order the commands are measured sometimes to assure that the results weren't being "biased" by some other movie/execution detail. And yes, they weren't, as the results were the same no matter which order I have used.

2. What was tested

I decided to test all the commands/syntax that came from Flash 4 but where supported by Flash 5, although not "recommended" anymore. They are, as follows:

2.1. Variable reading

In Flash 5, you can read a variable using the old slash-syntax (path:variable, as in ../mainwindow/userbox:name), or the new dot-syntax (object.variable as in _parent.mainwindow.userbox.name). The usage method is exactly the same.

Macromedia recommendation: "You can use dot syntax instead of the slash syntax used in Flash 4. Slash syntax is no longer preferred, but it is still supported by the Flash Player" and "Slash syntax was used in Flash 3 and 4 to indicate the target path of a movie clip or variable. This syntax is still supported by the Flash 5 Player, but its use is not recommended".

2.2. Object timeline control

Flash gives the user power to control virtually any object on your scene, and this includes playing with each objects timelines. Flash 4 had the tell target command that allowed the coder to specify other "temporary" targets using the same slash syntax, as in ../mainwindow/userbox and then issuing commands (like play or stop). Flash 5 doesn't need this tough (although the command is supported): you can control an object directly using the object.action syntax, as in _parent.mainwindow.userbox.gotoAndStop.

Macromedia recommendation: "The with action is now preferred over tellTarget becau e it i more compatible
with dot syntax", "...the tellTarget action is not preferred because it does not work with all ActionScript objects and is not ECMA-262 compliant" (Note: I have not tested it against the with command).

2.3. Object properties control

Other than issuing commands to control the timeline position of the objects, the user can also use commands to control the properties of the object itself, like its height or alpha (transparency). Flash 4 used the same slash syntax, and it had some commands to set the object properties - the set property command. You could use it on an object (like ../mainwindow/userbox) and pass the property you wanted to change and its new value as a parameter (_y and 800, por example).

Flash 5 can use the new dot-syntax to change an object's properties easily, simply using the object.property = value syntax as in _parent.mainwindow.userbox._y = 800.

Macromedia recommendation: Macromedia do not condone or recommend any of these ways, but on their examples they only use the dot-based syntax.

2.4. Object properties reading

Of course you can also read the objects properties. Using the old style syntax, you need a get property command and the same object reference as above. On Flash 5, you can read the object property directly, as in x = _parent.mainwindow.userbox._y.

Macromedia recommendation: Macromedia do not condone or recommend any of these ways, but on their examples they only use the dot-based syntax.

As one can see, there isn't much difference between the usage of the new and old style syntax - the only thing that change is the way to write them. In fact, the new way is much better, since it's simpler and more straighforward. I used to think that, even though writing them was different, when the SWF file got compiled they would be just transformed into some general, machine-code (executed by the plugin) syntax, and I wouldn't think x = _parent.y would be different from x = ..:y, runtime-wise (these commands do exactly the same thing).

3. The results

Without further ado, here are my results, after lots of testing to assure everything was running smoothly (this was ran in a PC, but you can see a mac version here, with the same results percentage-wise).

Have a look at it. Each of the four small tables measure one of the topics I have listed above. Then, each table has the command it was executed, the result on a box below (measure in miliseconds, for 60000 executions of the command), its equivalent on the new syntax below, and a box indicating the speed loss of it, in percents (the percent values are the only important numbers).

For example, executing x = ..:y 60000 times took 4.62 seconds, while executing x = _parent.y took 6.15 seconds, 33.16% more time, even though the commands do exactly the same thing, on the same variables, on the same levels.

Well, I can't express how am I surprised by these numbers; so I will let them talk for themselves. As you will note, all the commands executed have shown to be ran much faster using the "old style" syntax - that is, using the "supported" Flash 4 coding style on Flash 5 - than using the new "recommended" dot-syntax style.

4. Conclusion

Your Flash 5 scripts (and I emphasize: scripts) will be faster using the old, Flash 4, slash-style syntax than using the new, Flash 5, recommended dot-style syntax.

Final considerations and downloads

My results were reached using a PC (Intel Pentium 3 @ 450mhz, 256mb, Win98SE) using the standalone Flash player version 5, revision 42 (playerVersion WIN 5,0,42,0 - the newest). It was tested on the browser plugin version too to check the results. The tests were ran after a "cool" boot, without any other program/server/manager running.

I tried everything to do this tests as fair as possible. If you think there is some mistake on my benchmarks, I'm open to criticism and new tests.

Also, if you want, you can run the test yourself here and measure the results (this one only runs the commands 20000 times each, to reduce the chances of halting your machine). You can also download the original .FLA file I used on this test and look at the code: here it is.

Thanks for Sung from XConspiration for the Mac tests and screenshots.