If-else trees have some of the best performance of any conditional code, including if-else ladders, the ternary (? :) operator, and the switch statement. But how do they stack up against the O(1) lookups that Object and Dictionary offer us AS3 programmers? Today’s article finds out!
Posts Tagged object
AS3 has three kinds of loops—for, for-in, and for-each—but which is fastest? I attempted to answer that question about three years ago, but the article is in dire need of a followup as many version of Flash Player have been released since then and the question is core to our everyday lives as AS3 programmers. So which type of loop is fastest in 2012?
One of the new features in Flash Player 11 is a native JSON encoder/decoder class. In the Serialize Anything article, I neglected to add JSON as an option for serializing and deserializing arbitrary objects. In today’s followup we’ll take a look at the performance of the native JSON class and compare it to ByteArray.readObject/writeObject and XML.
The ByteArray class, introduced in Flash Player 9, has a pair of very powerful functions alongside all the usual ones like writeInt. It actually allows you to read and write AS3 objects and provides an easy, fast, and compact way to serialize anything without writing any code. Today’s article explores shows you how to harness the power of these functions to improve your data serialization and deserialization.
XML is widely used in AS3 applications for everything from simple configuration files to complex networking protocols. AS3 even includes 10 operators in its syntax specifically to make XML easier to work with. This often leads to AS3 developers loading XML documents and then just leaving them as an XML objects. XML’s performance begins to seep into the rest of the AS3 application. Today we look at just how much this can slow down our apps.
One of the very nice features of AS3 (and AS2 and JavaScript for that matter) is that you can dynamically access the fields of any object. This leads to much more dynamic code since you no longer need to know what field to access at compile time. As we’ve often seen with other dynamic features, this can come at a steep cost in terms of performance. Today we’ll see just how slow accessing fields this way is to get a good idea of just how much performance we give up when using this feature.
AS3 has an interesting feature that is sometimes used to great effect: dynamic classes. These classes can have fields added and removed to them and used like any other field. You can even make your own dynamic classes with the dynamic keyword. However, all of this fancy functionality comes at a steep performance cost. How steep? Read on to see just how steep.
There are three main ways to access the contents of objects in AS3: the dot (.) operator, the index ([]) operator, and the in operator. The first two are well known and functionally-equivalent because obj.property evaluates to the same value as obj["property"]. The in operator is different as I’ve described before: it returns a Boolean indicating whether or not the object has the given property. There are a lot of cases—error checking, for example—where we only care if an object has a property and not what that property is. So, can we improve performance by using the is operator rather than the index or dot operators? (UPDATE: hasOwnProperty results added)
A comment posted before the Flash Player 10.1 series of articles asked about the performance differences between creating an object with o = new Object() and with o = {}. Below I’ll look into the generated bytecode for these two approaches and test their relative performance to see if either approach is faster than the other.
I was reminded about the flash.sampler API by Grant Skinner’s recent post about it. While only available in the debug player, it can still tell us some valuable information about what goes on in the release player. Today I’m using the getSize function to find out how much memory overhead various classes impose, even when they are empty.