ActionScript Read/Write Performance

http://blogs.adobe.com/aharui/2007/10/actionscript_readwrite_perform_1.html
Reading, Writing and Arithmetic
ActionScript 3 (AS3) on FlashPlayer 9 has delivered on its promise of much improved performance. Sure, we’ll probably always wish it could be faster, but it is much better than ActionScript 2 (AS2). In AS2, everything was essentially dynamic. You could add properties to classes at runtime, change their types, modify methods, and all kinds of evil tricks. This required a certain amount of overhead at runtime to allow for this because you couldn’t know up front what a property was and how to access it.
AS3 introduced ‘sealed’ classes (classes that are not dynamic). Sealed classes cannot have properties added to them or those other nasty AS2 tricks. As such, the runtime can make assumptions about how to access that property. AS3 also implemented Ecmascript For XML (E4X) which made it possible to access the pieces of an XML hierarchy as if they were all objects, using the ‘.’ syntax. This is a vast improvement over the old way of working with XML in AS2.
One of the prices paid for this faster access is the notion of change detection. If objects do not have change detection by default, you can write to them faster as well. However, if you want to detect changes you have to add code to do so. AS3 provides a Proxy class that builds in change detection, and Flex provides [Bindable] metadata that the compiler detects and generates different code to handle change detection.
This means that there are a variety of objects (sealed, dynamic, proxy, bindable, XML, etc) that you can read from and write to in your application. These different objects have different read and write times. The basic runtime of AS3 is very fast so most if the time you won’t care about this information and will use the type of object most convenient to you, but in case you’re wondering, I put together a little test to see how fast things really are.
The test methodology is pretty rudimentary. Call getTimer(), save away the value, run a sequence of code, call getTimer() again and see what the difference is. Various things can cause errors in such testing, but a couple of runs showed reasonable consistency since I was most interested in relative time instead of absolute time. As such, your mileage will vary based on your environment, but here’s what I learned:
Reading
As promised, reading a variable from a sealed class is very fast. My tests accessed variables 200,000 times in just 2ms or less! Everything else was notably less fast, but remember, most of the time, this won’t matter to you, or the cost of optimization may be prohibitive, but here are the numbers anyway. The results will be reported in the following format: a title, a number, and my thoughts on the results. For this first batch of tests, the basic loop looks lke:
for (i = 0; i < counter; i++) {
s = obj.label;
s = obj2.label;
}
where obj and obj2 are local variables typed as sealed classes, Objects, XML or a Proxy subclass, so the compiler knows exactly how to access the data
Reading From Dynamic Object: 40
This means that reading from a dynamic object (created using { label: “foo” }) took roughly 40ms compared to the sealed class variable’s time of around 2ms. This implies that reading from a dynamic object is 20 times slower than reading from a sealed class. So, if you know the set of properties and access them often, define a class instead of using Object. You’ll also get compilation errors if you mis-type a property name.
The reason I’m just using numbers and not times in this report is because the actual amount of time will vary based on your computer’s speed, so numbers give you a relative feel. You’ll see that nothing else runs its test in 2ms, and that there are numbers in the 40-100 range which means that the difference is probably ignorable since it would take 2,000,000 reads to cost your application 400ms such that someone might notice a half-second. Scenarios with numbers in the 300-800 range might we worth your consideration for optimization, but remember, it still took 200,000 reads or writes to add up to less than a second of time.
Anyway, here’s the rest of the results.
Reading From Proxy: 350
That’s right, reading from a Proxy object is significantly slower!. But if you need change detection, you have to pay a price. While that number seems scary, note that it took 200,000 accesses to cost and additional 350ms, so like I said, many times you won’t notice.
Reading From Sealed Classes via Getters: 38
Many times, you’ll actually implement properties as getter/setter pairs instead of plain ‘vars’ because they can be overridden, more logic can be added to the getters or setters (especially to do change detection), or because the properties are defined in an interface. In fact, the vast majority of properties you access in a Flex app are getter/setters so you’re almost always paying this overhead. It is essentially just as fast as dynamic objects, but is much faster than Proxy if you also need change detection. Note also that these numbers are for the simplest getter that just returns a backing variable.
Reading XML Attributes: 550
Yes, that’s right, E4x is slow. But it sure is convenient, and if you had to use other functions to get at the attribute, it would be even worse. However, if you access the same attributes many times, it might pay to convert them to sealed classes or dynamic objects first. And this is simple obj.@label access, not some deeper fetch.
Reading XML Sub-Node: 750
Reading sub-nodes is even slower than reading attributes, so if you have a choice, attributes will be faster, but still not like converting to sealed classes or objects.
More Results
The first set of tests assumed you knew the type of the object you are reading. Often, we don’t know, or don’t know right away. For example, in an event handler, the event.target is typed as Object but you often know it is some other type, and arrays are not typed so when you are indexing into an array to get an object, you have to think about whether to coerce to a known type or not. So, the next set of tests I ran examined reading and writing when pulling objects from an array. The basic loop looked like:
for (i = 0; i < counter; i++) {
obj = arrObject[0];
s = obj.label;
obj = arrObject[1];
s = obj.label;
}
where the arrObject array might contain sealed classes, XML, etc, and obj is or isn’t strongly typed.
Reading From Sealed Class Variables (Coercion): 24
The benchmark for these test is reading when we have a local variable of the correct type and coerce the array entry via:
var lv:SomeClass = SomeClass(arrClass[1]);
That more or less says the price of coercing 200,000 times was some 24ms on my computer, so it is very inexpensive and will give you type-checking at compile time.
Reading From Sealed Class Variables (as): 30
This implies that coercion using “as” is slighly slower than coercion via a function as in the previous test.
Reading From Sealed Class Variables as Objects: 90
This says that it actually pays to coerce objects to known types before accessing variables, otherwise your reads can be 3 times slower.
Reading From Sealed Class Getters: 60
This says that coercion overhead starts to drown out the difference between access via vars vs getters, but there is still a cost. However, most of the time you don’t really have a choice whether to use vars vs getters.
Reading From Bindable Class: 60
This says that if you make a class [Bindable] you are converting the vars to getters and paying the required price for doing so.
Reading Objects: 45
This says that it is worth the cost of defining sealed classes and doing the coercion in the loop, unless the sealed class is using getters in which case it is slightly faster. I’d still go with sealed classes for the type-checking benefits.
Reading Proxys: 370
Proxys are slow. You should use [Bindable] on sealed classes instead. Note also that ArrayCollection is a Proxy so [] access is way slower than [] access of the internal array. It’s probably even faster to use getItemAt() than [] access.
Reading XML Attributes: 575
Reading XML Sub-Nodes: 770
XML is even slower than Proxys. As mentioned earlier, you’d have to access the same attributes quite often in order for it to be worth the cost of converting the XML to objects, but there’ll be occasions where it is worth it.
Writing
A similar loop was used to test writing to properties. We take objects from an array, coerce to a local variables if necessary, then write to a property. The results are:
Writing To Sealed Class Variables: 450
Reading may be fast, but writing is still slow, almost 20x slower than reading (450 / 24).
Writing To Sealed Class Setters: 930
Writing to the most simple setter that dispatches a change event is twice as slow as writing to variables.
Writing to Bindable Sealed Class: 1030
Bindable is slightly slower because it takes the time to do a value changed check before dispatching an event.
Writing to Dynamic Object: 500
Sealed classes are slightly faster unless they use setters, but that’s the price you pay for change detection and compile-time checking
Writing to Proxy: 830
Proxy is only better in this case because it didn’t send a change event. If it did it would probably be slower than sealed classes with setters.
Writing to XML Attributes: 580
Writing to XML Sub-Nodes: 950
No surprise here. XML isn’t very fast, but is very convenient.
Writing to XML Attributes That Have Binding: 7700
Writing to XML Sub-Nodes That Have Binding: 8900
This is the big surprise. XML data binding is very expensive in terms of the cost of modifying the XML data.
Arithmetic
The main takeaway is that XML is slower than objects, but its convenience might outwiegh the performance considerations. Note, though, that anytime you shove XML into an XMLListCollection all of the nodes get setup for binding so the cost of modifying those nodes might be measurable if you do a lot of modifications, and conversion to object may reap benefits.
There’s no easy way to test the speed of converting an XML tree to objects. Our WebService code has functionality that does the conversion, but the speed will depend a lot on the kinds of XML data you are getting. However, it has occurred to me that the conversion code converts the entire tree, and maybe a custom collection could convert on the fly and save the big hit of converting lots of nodes if the query returns a large chunk of XML when only a few nodes might be seen in a list. Hopefully I’ll get to that someday soon and blog about it.
Other than that, unless you really care about saving a tenth of a second here or there, you probably don’t have to think about which data types you are using, but if you want to impress your friends at holiday parties, you can memorize these numbers and recite them. To decide whether to optimize is pure arithmetic. Look at what it would take to convert to a faster access method vs how many accesses you are doing and what the expected payoff might be and decide from there.
Credits
Thanks to Scott from Fast Lane and Tracy Spratt for getting me started on this topic
Additional Information about XMLListCollection
In Flex 2.x, XMLListCollections eat lots of memory. That’s how I originally got started on this topic as Tracy pointed me to Scott’s blog. I’m unconvinced that it is really a leak, but the memory utilization is such that it doesn’t matter. This kind of memory utilization can cause paging in the operating system and exacerbate the performance cost of using XML. Changes were made in Flex 3 Beta 2 to address this problem and memory utilization is better and bounded, but still not as good as objects, so some of you may also want to convert from XML to objects for this reason as well.