I’m not talking about making sure that you removeEventListeners and nullify unused objects for garbage collection, that is a given. These are common tweaks that people could use in every application but often we don’t because we suspect that the performance hit isn’t as big as it is. Here we will look at how big that hit actually is.

For all these tests I used Grant Skinner’s Performance Testing Harness. The numbers for the tests are provided along with the source code and the test available to run. I slightly modified the Testing Harness so that I could also get the times and numbers out of each test for graphing purposes.

Array vs ArrayCollection vs ICollectionView
These tests all started when I wondered how much slower iterating through an ArrayCollection was than iterating through an Array. The numbers were staggering. In some cases, iterating through the Array was 1/50th of the time or 5000% faster.

For my test I also was curious if using an interface instead of using the actual object made a difference. As you can see from the numbers that the difference wasn’t hugely significant, but actual.

One rumor that I heard was that ArrayCollections are faster at finding a specific index value than Array’s due to some sort of magical optimization. So I tested that rumor also, below are the results. As you will see, this rumor is false. Arrays are faster at accessing a specific index value than ArrayCollections.

Already there are additional tests I am thinking about running, but on the whole you can see that using the base Array over ArrayCollection will yield large performance improvements.

However, I again want to point out that whenever you set an Array as the dataProvider of a Flex component, Flex components convert Arrays to ArrayCollections. So don’t try to get a performance increase from a component specifically by setting the dataProvider as an Array, the Array will be transformed either way.

Loops
The next section that I was going to test was the age old debate about the perfect loop: For Loops vs While Loops, iterating before the loop vs after the loop, etc etc. Luckily for me, as soon as I started looking at Grant’s testing harness, he had already created most of the test cases for me (Thanks). So the only extension to the test that I had to make was to also test against iterating before or after the loop (++i vs i++). The results can be seen below.

What you will probably notice is that no specific loop includes massive performance improvements, though the simple for loop seemed to be the fastest on average. So take your pick and run with it.

Unrolled Loops
The next tests that I came up with was to see how efficient rolled vs unrolled loops were. The reason I felt this was important is there are times that we needlessly iterate through a loop when we know there will always be X number of elements. When this is a the case I’ve found (and the tests prove) that it is faster to just do what you need with the X elements rather than write a loop to iterate through the elements.

Remember to check the source to see the implementations of these different tests.

Length Reference Variable
This is definitely a nit picky test, but I had to know the truth! When iterating through a loop is it significantly better to get a reference to the length of the loop, or is it okay just to use array.length in each iteration. As proven, using a variable to store the length is significantly better.

Reference Variables
When iterating through a loop I often like to pull a reference to the current value that is being evaluated in a loop. I do this mainly to make reading the code easier, but I was curious if this creation of a new reference would be harmful to performance. On top of that I was curious if giving these temporary variables a type was helpful for performance or not. Below are the results.

As you can see I’ve figured that there isn’t a significant performance increase or loss with using temporary variables. I think I’ll keep using my temporary variables to make reading easier.

Type, Cast and toX
The next series of tests are extremely geeky tests with some startling results. Is it faster to say (object as String) or String(object) or object.toString? This test case and many others are included below for each of the base types. May this help you decide how to type and cast your variables.

The big one to notice is the amount of time it takes to String(number) instead of saying (number as String).

Included with each test is the control case of casting and typing each type to the same base type.

Remember when using “as”, if the conversion fails, you will receive a null rather than the value. Unless you explicitly know what the type will be, it is always good to make this check.

The “new” operator
I’ve always been told that when creating a new base type that you should use the value rather than new because it saves the need for the VM to allocate the memory in the heap. But what was the ACTUAL performance improvements. Again, the numbers are staggering. For the next tests I created each of the simple types 3 different ways.

The first way I used the new operator as such: var s:String = new String();
The second way I used the new value as such: var s:String = “”;
And the final test was to create the variable with the new operator without the final parenthesis, such as: var s:String = new String;

For every test setting the value rather than using the new operator was almost twice as fast. The biggest difference being with creating a new Array, using the [] operand instead of the new operator was almost 3 times as fast.

I should also point out that for almost each test, using the parenthesis was slower than leaving them off when creating a new variable, though this is considered bad practice. Though the difference was marginal.

Static Methods vs Class Methods
As a side curiosity I was wanted to know if there was any performance loss or gain based on the types of functions used within a class. I was able to see that there weren’t any significant performance improvements over one type of function or another. So stick with best practices within your classes and only make methods and properties public when they absolutely have to be.

This test does not include testing whether creating the class and then accessing the function is better than a static function which does not need to instantiate a class.

Using “this” and Other Class Curiosities
This next section includes many different tests to improve my class creation.

Setting the default values
In this test I was curious if it is better to initially set a variable in the constructor or at the variable, and also if setting the variable defaults inside the class vs outside the class was better. What I found is that it is faster to initially just set the variables to their default value rather than making this change in the constructor.

Is using “this” wrong?
Checking whether it was faster to use the “this” identifier was harmful to performance I concluded that there was no significant performance loss or gain in using the “this” identifier.

Getters and Setters vs Direct Accessors
Lots of good ole’ boy Java developers will tell you that every property has to have a getter and setter. Other programmers will say that this is only necessary if there is some logic that needs to run in the get/set process. Now you can see that by using a getter/setter when a direct accessor can be used is wasteful for performance and typing. Therefore, only create getters/setters when it is important to run some logic in the getting/setting process.

Size really doesn’t matter… in variables.
Finally, the stigma from writing Javascript applications always left me feeling guilty about using full words when a letter can do. In Javascript this was a performance issue and caused many programmers to use single incomprehensible letters instead of easy to read words. To elevate my guilt I decided to test if using long variable names made any difference at runtime. The answer is no. No savings, no loss. Now, guilt free, I will always use well written variable names instead of short single letter descriptors.

If..Then vs Switch..Case
Like loops, developers argue which logical test is better: if..then vs switch..case. Pitting the two against each other, apples vs apples, I’ve found that if..then statements are slightly faster than switch..case statements. I will still use each statement where appropriate though, but it is good to know in the situations that I have the choice that I should use if..then statements.

Math.max() vs Math.max.apply()
One little known secret to AS3 is the apply method. Most classes have more than one way to skin a cat, and the apply method is that function. In the case of Math.max (or Math.min) I was curious how much faster the apply method was vs logically finding the largest (or smallest) value. The numbers were staggering. From now on I will be using the apply method whenever possible as it is a very low level and fast function.

Final Thoughts
Obviously the things in this list I see as some of the greatest offenders and also the easiest to fix. It all comes down to you and which changes you feel comfortable making in your daily coding practices. Some of the more “nit picky” performance changes I feel can effect code readability and reusability, and which you implement into your code is up to you and your coding practices. Hopefully this ends the debate between some techniques as being the end all be all technique.

If there are other coding techniques that have left you wondering which is better, let me know and I’ll add it in. I’m sure over time I’ll revisit these test cases.

The Test, Run It For Yourself Or View Source

View Source (or right click swf)

There are two main ways that I see people embed fonts.

1) Straight @font-face embed via Flex CSS
2) Embedding the font into a Flash File, selecting the glyphs to embed, and then embedding the resulting SWF into Flex.

People use the first one for simplicity and the second (definitely more difficult route) for optimization. Yet people keep forgetting (or never knew) that there is a third route that provides simplicity and optimization.

First, the basics…
In your Flex CSS file (or in the style block) start up a new font face block.

Next provide a direct path from your application’s root folder to the font. For ease I usually make a copy of the font and stick it in my assets folder so that other people connected to my project can still build the app.

Now name the new font-face so it can be referenced as a font family.

Next you need to add some description to the font. Is it a normal font?

Bold?

Italic?

Bold and Italic?

To have all four of these options you would need to embed each of the different fonts that include all these options. They can all be under the same fontFamily name, but with different configurations. But if you are missing the bold font and trying to make your text bold you will not be getting the desired look.

If you are confused at all by the different @font-face blocks below make sure to look at the actually font file name. You will notice each is just slightly different with the different look.

Next you need to set whether your font is using advanced anti aliasing. This takes slightly more processing, but can make your fonts look nicer at larger sizes. This is dependent also on whether the font type supports it. Usually, I just set this to true.

Now with Fx4 you have something new to worry about: CFF. If this is set to true, the font will be available to the new TLF engine and Fx4 (Spark) components. If CFF is set to false then it will be available to Fx3 (Halo) components. Yes, right now you need to embed two fonts to get this to work for both. In the future this may change.

And now, the optimization…
You may have hit some issues with all the previous steps, or not – but here is the optimizations. Within the @font-face tag you can set which unicode characters to embed – this is like selecting the glyphs in Flash. To find a helpful table of common unicode characters and ranges that people use refer back to your flex sdk, specifically: flex-sdk-folder/frameworks/flash-unicode-table.xml. After looking through the table you can select your desired ranges that you want included with the font embed. The more unicode characters the larger the final SWF file will be, the fewer, the smaller.
My final @font-face embed statement.

Profit!
That’s it, embedded and optimized fonts. I’ve actually tested the size of the resulting Flex App SWF files after going the long route and the route shown here. Both resulting sizes are exactly the same, down to the last byte.

The itemrenderers are nice. Lightweight. Definitely check out the itemrenderer’s code. Very simple.

What these components do is “hold” or “lock” a selection. In these examples you may say “well that is similar to shift/ctrl select”. Yes and no. If you need to hold nodes that may become difficult in large lists and in my apps I do lots of list filtering and sorting, so now I can filter for a specific node AND keep locked nodes. Very helpful.

Special thank you to John Gorena who already pointed out that this is something helpful for mobile development. Enjoy!

This was a presentation that almost wasn’t though. For those who don’t know, this presentation was originally planned to be presented by Sean Chistmann of EffectiveUI, yet as he fell sick Adobe called Jun and myself to fill in the gap. Working closely with Jun and Sean (when available) we added our own personal touches to the presentation and presented on Tuesday and Wednesday of Max. Again, thank you to everyone that attended either of the sessions and all the great feedback we received.

Tackling Memory and Performance in Flash, Flex, and AIR
Presentation Source Files

Below is a list of helpful resources for continued education in this subject:

Livedocs

• http://livedocs.adobe.com/flex/gumbo/html/WS6f97d7caa66ef6eb1e63e3d11b6c4d0169-8000.html
• http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/flash/sampler/package-detail.html

Flex Profiler and flash.sampler.* classes:

• http://blogs.adobe.com/aharui/2008/09/using_the_flex_builder_3x_prof.html
• http://www.slideshare.net/srp1970/overview-of-flex-profiler/
• http://lists.motion-twin.com/pipermail/haxe/2007-August/011362.html
• http://www.jinten.net/blog/archives/47
• http://ticore.blogspot.com/2008/05/as3-observe-object-size.html
• http://www.insideria.com/2008/06/profiling-flex-applications-sa.html
• http://stopcoding.wordpress.com/2008/04/26/lets-talk-about-the-flex-profiler/

AVM2 and MMgc:

• http://www.adobe.com/devnet/actionscript/articles/avm2overview.pdf
• http://developer.mozilla.org/en/docs/MMgc
• http://www.gskinner.com/blog/archives/2006/09/garbage_collect.html

Performance and Memory Management:

• http://en.wikipedia.org/wiki/Performance_analysis
• http://en.wikipedia.org/wiki/Memory_management
• http://www.adobe.com/devnet/flashplayer/articles/resource_management.html
• http://www.slideshare.net/dcoletta/optimizing-flex-applications/
• http://www.adobe.com/devnet/flex/articles/as3_tuning.html
• http://adobedev.adobe.acrobat.com/p71169528/
• http://www.insideria.com/jun-heider/
• http://www.gskinner.com/blog/archives/2006/06/as3_resource_ma.html
• http://blogs.adobe.com/aharui/2007/03/garbage_collection_and_memory.html
• http://www.moock.org/blog/archives/000223.html
• http://blog.flexmonkeypatches.com/2007/03/28/flash-player-memory-management-and-garbagecollection-redux-2/
• http://olegfilipchuk.com/2009/07/24/unload-you-module/
• http://www.colettas.org/?p=115

Data Transfer and Performance:

• http://www.jamesward.org/census

Elastic Racetrack:

• http://www.onflex.org/ted/2005/07/flash-player-mental-model-elastic.php
• http://www.craftymind.com/2008/04/18/updated-elastic-racetrack-for-flash-9-and-avm2/

AIR/Flash Player Mac Idle CPU:

• http://www.gskinner.com/blog/archives/2009/05/idle_cpu_usage.html
• http://blogs.adobe.com/air/2009/05/performance_tips_for_adobe_air.html

Flexcoders:

• http://www.mail-archive.com/flexcoders@yahoogroups.com/msg86385.html
• http://www.mail-archive.com/flexcoders@yahoogroups.com/msg83781.html
• http://www.mail-archive.com/flexcoders@yahoogroups.com/msg95073.html
• http://www.mail-archive.com/flexcoders@yahoogroups.com/msg92116.html
• http://www.mail-archive.com/flexcoders@yahoogroups.com/msg86738.html

Adobe Bugbase (Please vote for these bugs!):

• http://bugs.adobe.com/jira/browse/SDK-15731
• https://bugs.adobe.com/jira/browse/SDK-14820
• https://bugs.adobe.com/jira/browse/FP-2009
• https://bugs.adobe.com/jira/browse/SDK-14781

No one seems to know how to actually implement MVC and I can’t stand it!

Too many programs out there set up like a procedural php page (front top to bottom): imports, sql statements, data, methods, and a ton of html. This is not how to set up a page, and even more so this isn’t how you set up an entire application! But people do it, don’t ask me how or why, but it’s a mess.

I want to let everyone know that the following “worst practice” example is actual code shown to me very recently. I simplified it a bit but ultimately the Flex application was one large mxml file.

You may try to argue that MVC takes more time to setup, more coding, “harder to read”, or whatever other arguments I have heard, but in the end it is easier to program, loosely coupled, simplistic, dry, object oriented, and finally best practice.

If your code looks like this, you are doing it wrong! (Worst Practice)

This is an extremely simple example and honestly if this is all that your application needed to do then you are done. If your application is more complicated – or will get more complicated than this example – then this will fall apart real fast. On top of that good luck being able to unit test this code, reuse any of this code, using object oriented designs such as factories or even just interfaces, or even using the outliner view to find specific methods. Our final MVC application will be able to do all these things.

Quick Look At MVC
MVC is a simple concept that is immensely helpful at simplifying application development. The concept is just to split up your application by it’s model (the data), the view (what is seen), and the controller (the methods and functions that move the data from the view to the model and back).
Wikipedia – MVC

Understanding The Model
The models are your data centers for the application and extremely simple. In actionscript when you create models, this is the exact time you will want to use getters and setters for your properties. Why? Because the model just holds data and when the model has changed, it releases events to alert anything listening that the model has changed.

Best Practices: All of the properties in your model should have setters and extend the EventDispatcher to be able to send out events when the model has changed. You can see what I mean in my model code below. You could always use custom events to send let your application know of property changes, but for my example I will just use the basic Event class. It is also Best Practice to check that the property has actually changed before sending out events and updating the value. Double check that the variable has actually changed first. Very easy with strings and numbers and such, a bit more effort for larger complex objects.

Refactoring Your Code To The Model
For our example the model is EXTREMELY simple due to only one property, but you can see how simple the model is and how well it separates and simplifies the application layout. Finally you can now reuse this model in multiple controllers.

Understanding The Controller
Controllers are nothing more than a class that contains methods to move data back and forth from the data, update and handle responses from the view. I touched on this earlier but by separating this code into it’s own class you can have interfaces, subclasses, use unit testing on individual methods, and finally use the outline to jump to specific methods. Basically, everything that will help you grow as a developer as you make bullet proof applications.

Best Practices: The controller includes whatever methods are necessary and a reference to the view. The methods/handlers that are required by the view will always be public, everything else is private or protected. All events handlers should be in the controller and then the controller modifies the model and/or changes the view. However the view NEVER directly accesses the model. Again, my events from the model are just straight Event classes, though you could always make custom events from your model, though it is probably a bit overkill. Notice especially that the model is set to private to protect it from the view and other components. If you wanted to allow accessors to specific data within the model you may want to add getters in the controller, though again this is highly discouraged.

Refactoring Your Code To The Controller
Setting up your controller is simple, let’s start with a blank class.

Now we just have to move the methods and change the functions that need to be available to the view to be public. Notice that the controller includes a model reference and listens for changes to the model and then updates the view as necessary.

Some people will argue that the httpservice should be in the model rather than in the controller. This is a point of contention among some developers. I believe it should be in the controller (or in a simple command) because it is a piece of logic that requests the data from the server, not the data itself.

Your Simplified View
Finally we will refactor our view to just the view elements and making a reference to the controller instance in your declarations section (for Fx4).

Looking over this code you will notice that there is absolutely no logic in your view, keeping you view to only doing one thing, looking good. It is the controller instance that receives events from the view and the controller that houses all of your application’s logic.

Wrapping It All Up
Hopefully this is illuminating and pushes you to do some code refactoring. What is also great about this style of programming is that it works right in with any of your favorite frameworks. If you are making an application and are wondering “Where does this code go?”, you just have to ask yourself “is this part of what is seen, the data, or logic within the application?”. This separation will also make it easier for when you are working with junior developers and they don’t know where to put code. I am sure you can already see the benefits to not having services in your view and being able to reuse controllers over multiple views, and the ability to continue abstracting your code to new levels.

Good luck, and happy coding!

The idea of best practices (in my opinion) are a set of rules to program by that don’t get in the way of programming while keeping a consistent, high-quality level of work while leaving minimal (to no) room for error based on coding practice not coding.

Basically, don’t keep coding around the problem and adding additional coding to fix the problem, just use best practices and more on.

Right now I am going to focus on events, arguably one of the most used set of classes in the Flex framework. For this set of examples I am going to assume that the developer knows that they have to AT LEAST extend the Event class for all events.

So, some bad code…

Naming

Wow, this code is bad right from the start. Notice the class name badevent. In Actionscript we follow the camel case naming convention. As such the name of this event should be badEvent. Notice that each word in the name of the class should start with an upper case (with the first word starting in lower case). Now classes are special, classes start with an upper case, so the FINAL name of our event should be BadEvent.

Next…

Typing your variables

I’m not EVEN going to start in on the naming of properties, but I will complain about the object typing. When the AS3 compiler sees an object it will create room for it in memory, but unlike a typed object it doesn’t know how much room to make, this is bad for memory. On top of that, the compiler can’t do type checking for you at compile time, so you have a greater probability of runtime exceptions in your application.

Quick update…

Now that little type change fixes our problem of type checking and memory performance.

There are many other steps a developer must take to TRULY captialize on memory performance, this is just one drop in the bucket.

Protecting your properties

However there is another problem with the properties on this event, they are exposed to change as it moves through the application. What I mean is: As the event is fired, it is very possible that there will be multiple listeners for that event. As the event hits on handler function the handler function may update the property. Now when the event gets to the next handler function the original data from the event has changed. This is unwanted and may lead to unexpected effects in your application.

Using getters we limit the properties from changing. We also will set the properties on the constructor so that the property can only be set when the event is created.

There may be a time you REALLY want to have the property able to change in an event as it moves through the application. I would highly discourage this as it works against best practices. As the event bubbles the changing logic in the event may be hard for future developers to follow or even find in the code.

Please notice also that all private variables start with the underscore “_”. Using this makes it so that you don’t have to roll over each variable or look in the outline to see if it is private or not.

Clone function
As an event bubbles through the application, or if you need to make a duplicate of the event, you call the clone function. However, if we don’t state the the clone function will return your newly created event type it will, by default, return just a normal event. This is highly undesirable for your application. So next we override the clone function.

You will see here that we have created a new event instance and passed the variables available to this event into the new instance. and returned that instance. Very simple bit of code that will protect your program.

Event types
Now we need to create constants to describe what action this event is representing. This is very simple and very helpful. As event listeners are ultimately looking for a string match you COULD type the string right into the listener…

If you have a developer like me that can’t spell or adds the wrong tense, then I may accidentally do this…

Now we spend all day looking for why the handler is never being called. Again, this is solved with some constants.

Now with the constants the intellisense will give me some assistance and I get the following code for adding my event listener. No possibility for spelling and grammar mistakes here.

Also notice that the constants we difine is all in upper case with underscores between the individual words. This is another best practice and camel case naming practice. Again, this just quickly alerts other users that this is a constant.

ASDoc
Finally, before we lock up any class we add ASDocs for future developers. Below is the FINAL class.

Conclusion
Some people would ask why write a blog post that is so simple. I wrote this one because all the bad examples presented I have witnessed in life code over the last few weeks. I am sure that is both surprising and not surprising.