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.
Archive for category AS3
Five months ago I said I’d talked about explicit type conversion. I hadn’t, really. What I talked about before was type casts. A cast changes the type, not the data. Today, I’m actually going to talk about type conversion and show you the costs of converting between all of your favorite types: int, uint, Number, Boolean, String, and even XML.
When you construct an Array or a Vector, you can specify an initial size. Why would you do this?There are various reasons you may want to reserve initially-unused slots for logic reasons, but are there any performance gains to be had by pre-allocating this space for an Array or Vector you intend to completely fill right away? Today I’ll take a look to see just how much performance can be gained by pre-allocating Arrays and Vectors.
Today’s article is about a hack. It’s a hack dedicated to improving the performance of helper functions, nested or not. you may not like the way the code looks, but you’ll love the speed!
In AS3, you can create an Array can be created with special syntax: myArray = []. You can even fill the Array with values all in one go: myArray = [1,2,3,4,5]. This is a nice shorthand that saves some typing compared to using the constructor: myArray = new Array(1,2,3,4,5). But, which way is faster? Today we find out! UPDATE: added a third way of creating arrays
It’s been about 9 months since my last test of AS3 versus JavaScript and there have been several major releases. I’ve held off on an update to this series since the two most widely used browsers—Internet Explorer and Firefox—have been approaching significant new versions. In the meantime, Adobe has released Flash Player 10.2 as we’ve seen in my performance update series (part one, part two, part three). Today, we pit every major browser against each other and Flash Player itself to get an updated idea of which provides the fastest scripting environment on the web.
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.
Recently, I’ve seen a lot of performance-critical code that has made heavy use of field variables. For example, an expensive loop might look like this: for (var i:int = 0; i < this.numObjects; ++i). I've recommended to some of the programmers writing such code that they modify it to cache the field variable as a local variable to improve performance. Was I right to recommend this? In today's article I'll examine the read and write times to see if caching field variables locally really improves performance.
Today’s article is a followup to a flawed article I wrote last October. Skyboy’s comment brought this to my attention, so today I’m (hopefully) correcting the problems with an important test: AS3 operators. Read on for the updated test code and results.
Today’s article is the conclusion of the series updating my performance tests in light of the newly-released Flash Player 10.2. If you haven’t read part one or part two, that would be a good place to start. If you already have, read on for the conclusion!