In part one of the Flash Player Internals recap we covered how the player is built, for part two we talked about how the player infrastructure works.  In part three, we will examine how ActionScript and the Virtual Machine (VM) are improving in Flash Player 10.1.

What's New, Player-cat?

First off, Lee announced that the ActionScript VM has been updated to use the newest version of nanojit, which is the same VM backend that is used by Firefox 3.5.  This is an important update not only for performance, but because it supports many different processors.  Processor support is critical when you are looking to run the VM on as many devices and platforms as possible and nanojit helps the Player team do this.

The Player now has a much improved internal String class.  Strings have always been a bit of a bottle neck in Flash and the player team has updated the new class to allow better caching, faster string comparison, and most importantly lower memory usage.  This kind of low level update is great because it improves how our applications run without having to change a line of code.  Of course, you need to republish existing applications for 10.1 when it comes out (recall how the player versions SWFs), but the gains should be worth it.

On the memory front, the Player team has spent a lot of time focusing on how to use less of it more efficiently.  The first step they took is to have the VM take up less of a memory footprint.  Lee didn't get into any details but I would assume nanojit helped with this.  The other area they looked at was Garbage Collection (GC) and how it could be tuned for mobile devices.  What they have found is that memory usage has dropped anywhere from 10-50% for existing applications.  The GC tuning wasn't the sole update for this huge improvement, we will look at some other updates in part four, but this was a big one.

Garbage in Garbage Out

Anyone that has worked extensively with the Flash Player, starting with Player 9, has eventually run up against the Player's Garbage Collection (GC) process.  GC is another one of those community hot topics, one that I don't feel like exploring at the moment.  If you haven't explored GC in the Flash Player yet, you really, really should. Grant Skinner has an excellent article about how the GC works over on Adobe's ADC site, it is very much worth your time to read.

The big thing about GC that Lee hit home was that, GC is NOT memory management.  This seems to be a confusion point for a lot of developers and when their app is all bloated with excess memory usage, they point their finger at the GC saying it is the cause.  The reality is, that most memory issues are developer created.  If you don't take the time to clean up after yourself, i.e. remove event-listeners, strong references, etc. then there is nothing the GC can do to help you.

The key thing about memory management in Flash is to think about it from the very beginning.  The development team that built the New York Times AIR-based reader implemented an IDisposable interface that allowed for self-cleaning of objects before throwing them away.  Aaron and I used a similar approach called IRecyclable for the Scion 2007 redesign.  The idea is that you create a method on your object called dispose() that removes/nulls out all internal references within the class.  If Class being disposed haves children objects that implement the interface, the class' dispose method call dispose() on the children.  By having this kind of system, you can make sure that your code is self-cleaning at runtime.

Another tip that Lee threw out was using prime numbers when leveraging the Flex Builder profiler.  Create 7 instances of something and then look for the number 21 in your instance counts after the app has been running for a bit.  The theory is that by using prime numbers as an instantiation number, you can find hanging instances faster by looking for multiples of that number.  In the 7/21 case this is caused because you have three instance of the first 7 you generated, which may be a bad thing, that is up to your code and how many instances you expect.

Tada! It's Alchemy

If performance matters, and we mean really matters, then Lee recommends investing time in learning both Alchemy and C/C++.  For those of you not familiar with Alchemy, it is an Adobe Labs tool that converts C/C++ based libraries to AVM2 byte-code.  This means that you can execute your C/C++ code from within in your Flash application and it is incredibly fast.  Lee talked briefly about how it uses a special memory system based on byte arrays that make the code execute quickly and lightly within the Player. At DevelopmentArc, we haven't had the chance to really dig into Alchemy yet, but the examples are pretty stunning.

The other technology to leverage for pure performance is PixelBender and the Hydra language.  PixelBender is a new engine within the player that is designed for fast execution of image/math based data.  Its important to note that PixelBender is not supported on a lot of mobile devices (at least not yet) so this is really more of a desktop/browser feature, but if speed is your thing, then you should look into it.

That's all for part 3, in the final section we look how the Flash video and rendering system is being updated.

[ Read Part 4: Flash Player Internals 10.1 ]