I recently received an e-mail from asking which is faster: a DisplayObjectContainer or a Vector of DisplayObject. To ask this is to question whether or not we can do better than the Flash Player’s native container of DisplayObjects using AS3. It turns out that we can. Read on for several ways to improve on DisplayObjectContainer‘s speed.
Posts Tagged vector
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)
Both Array and Vector have some methods that allow AS3 programmers to do some functional programming: every, filter, forEach, map, and some. These can lead to flexible and concise code, but at what performance cost? Today I’ll test them to get a handle on just how much speed you’re giving away by using these methods.
The differences between Vector and Array have been quite interesting since Vector was introduced in Flash Player 10. Until just recently I didn’t know that there was special syntax for declaring a Vector akin to Array's special a = [1,2,3,4,5] trick. This got me thinking about the various ways one can declare a Vector and, of course, how they’re implemented in bytecode and what the speed differences, if any, are. Read on for some nitty gritty about how you declare Vectors in AS3.
It struck me recently that there are a lot of ways to convert variables of many types to a the String type. The ease of doing this is one of AS3’s strengths over languages where it’s error-prone, possibly insecure, and just plain difficult. The C language is the most obvious example of this and, since then, seemingly every language has enshrined string conversion in ways ranging from global String() functions (AS3) that take any variable to adding toString() to the base Object type (Java, AS3, others). AS3 seems to have chosen “all of the above” and there are now many ways to convert to a string. Below I’ll look at them from a performance standpoint and see if the everyday, run-of-the-mill boring string conversion can be improved by choosing one option over another.
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.
Today’s article is in response to some interesting comments on the previous article comparing Array‘s performance to that of Vector. Today I’ll test different types of Vectors and the performance of deleting elements.
Amazingly, I’ve never done a straight shootout between Vector and Array on this site. It’s a simple test, so read right on to see what kind of added performance you can get by using Flash 10’s Vector.
I recently received an e-mail from Dmitry Zhelnin (translation) with a test he did concerning the speed of a couple ways to get a value for a key, which I like to call a map and Wikipedia likes to call an associative array. I’d been meaning to do a similar test for a while now and, guess what, I finally have! UPDATE: fixed miss test for fixed-size Vectors.
AS3 gives you a good number of potential ways you can loop over collections. When Flash Player 10 first came out, I went ahead and tested out the new Vector class in a variety of ways. One of them was to pit it against the collections available in Flash Player 9: Array, Object, Dictionary, ByteArray, and even BitmapData. Below I’ll show you my test and discuss its results.