A better as3 compiler? The logical consequences that never happened

More than an year ago, Joa Ebert posted a brief summary of the “logical consequences” of Adobe’s opening of the Flex SDK sources: now that the sources for the actionscript compiler were open, the community was free to branch out a more advanced one. Function inlining, mixing as3 and opcodes, optimised integer math (I do NOT want to work with Numbers), compile-time evaluated constant expressions; the list of possible enhancements is long. Why bother? Because the as3 compiler makes little use of the avm2′s true performance potential (things got worse with fp10 and the unavailable to as3 Alchemy bytecodes), performs no compile-time optimisation of your code and outputs redundant bytecode overall, especially in the case of integer arithmetics.

An year passed, and noone really raised the question again. Well, maybe kind of. Alchemy did create quite a buzz, due to the obvious absurdity of c++ being quicker than as3 when compiled down to abc, and some of the mighty few did start thinking about how (and why) on earth would such a thing be possible. Some explainations came along, and the dark magic of the LLVM kind of concealed the fact that the one and only as3 compiler is crap. Note that the Alchemy compiler overcomes the shortcomings of the as3 compiler by outputing assembler when necessary.

Well, if the dreamed of as3 compiler is a far-fetched thing to strive for, Joa Ebert’s as3c gave the community a glimpse into the potential for extention of the existing asc. As far as I know, as3c is still the only way to inline assembler in the body of a program that will boil down to abc. Joa’s efforts have been pretty much discontinued however and some opcodes are left unimplemented. Also, the as3c workflow is kind of heavy – one could hardly wire as3c into FlashDevelop for instance.

On the other hand, there is a way to produce highly optimised abc, if one is ready to give up the language. Nicolas Cannasse‘s haXe has pretty much all the language features an as3 coder craves for, such as enums, type generics and, recently, an api to the new avm2 Alchemy-related opcodes. What trully rocks the boat is that the haXe compiler has ability to boost code performance in the avm2 to a much greater extent than what compiled as3 gets: indeed, the haXe compiler boasts with features such as function and constant inlining, optimised integer math, and also a strong expression optimiser that does some last minute code refactoring for performance. Finally, the haXe format library even enables you to write in assembler, which you can assemble to bytecode, load an run on the go.

But seriously, if one guy can design an entirely new language, able to compile down to highly optimised avm2 bytecode, with all the language features missing in as3, why can’t an entire community (and an interested corporation, for that matter) produce a better compiler for the already exisiting as3? Obviously, it is noone’s responsibility to take on this task (community-wise; Adobe should take the matter seriously); but in my humble opinion it’s everyone’s responsibility to be talking about it.

I believe that we should put forth a community project which would at least define some of the parameters of the as3 compiler of tomorrow.

P.S. A question about haXe and format.abc: Nicolas, is there no way to make bytecode insertion happen at compile time in haXe (as opposed to during runtime with the format library?) Generating and loading swf-s is extremely sweet, but ties one down to writing entire classes in opcodes; mixing haXe and opcodes, with an asm{} keyword for instance, would be much more flexible, and absolutely amazing.

Bookmark and Share

Flash/as3 custom namespaces and performance: the name qualifier is slow

I was thinking about how to organise the classes of one of the frameworks I’m working on these days. Two options: either dump everything in the same package, and make everything internal, or use namespaces to keep the API clean.

So, yeah, namespaces sounded like the right way to go. A lot of the functionality in the framework involves deep tree tranversal however, so I found myself thinking about the performance implications of using custom namespaces on ‘hot’ properties.

I put up a little benchmark to see whether namespaces slow down code execution. It runs four tests: a for loop that extracts a value from a public property of the object of the calling method, one that accesses a protected property of the object’s superclass, one that accesses a property in a custom namespace after a ‘use namespace’ statement, and one that accesses the property with the :: name qualifier. You can get the sources here.

On my notebook, the test (running on release player 10) output the following:

Accessing a property in the public namespace.
>	Running test @ 1000000 iterations ...
	Execution took  0.003  seconds.
Accessing a property of the superclass in the protected namespace.
>	Running test @ 1000000 iterations ...
	Execution took  0.003  seconds.
Accessing a property in a custom namespace.
>	Running test @ 1000000 iterations ...
	Execution took  0.003  seconds.
Accessing a property in a custom namespace with the :: name qualifier.
>	Running test @ 1000000 iterations ...
	Execution took  0.263  seconds.

Properties in the custom namespace were just as quick to access as those in the ‘built-in’ namespaces when made available with a ‘use namespace’, and ridiculously expensive when accessed with the name qualifier.

Brief, avoid using :: in loops when performance is at stake.

Bookmark and Share

The much dreaded Singleton

I have come across so much contempt towards the Singleton, it’s almost scary. Singletons are crucified all over the place, and whilst there are very sound theoretical reasons to avoid abusing the pattern, the Singleton has a healthy place in ui programming.

More often than not development for Flash puts us against unique instances of things. Usually, this happens in the context of UI programming: a single stage, a single mouse, etc. Some aspects of many applications are also better off built centralised, for sometimes one simply wants to avoid two objects performing clashing updates on something (a good example is animation of gui components and overwriting of property interpolation tasks in tweening engines). In such situations, one who blindly aims to avoid building a Singleton most probably ends up isolating the shared state needed to sync the instances in static vars and methods, achieving (in the best case) something that looks more or less like a Borg design. New catchy notions, same old enemy – global state.

Speedy

This has nothing to do with loose coupling or design patterns, but a Singleton is usually a better alternative to static vars and methods for at least one big reason. Static stuff in Actionscript is very slow to access. (What was it, 10 times slower?) A call to a method on a singleton will make use of one static var lookup – the reference to the singleton – and that only if a reference to the object is not already locally available. The same method, if declared static, will probably have to access at least one more static variable in order to read and write global stuff. [EDIT: This is not entirely correct, see the follow-up benchmark on static access performance.]

It seems that in Python sharing state among instances is considered more elegant than using Singletons. One could easily extend the same logic to Actionscript: more transparent code, good-looking instantiation with new, etc. Still, if more than one static var is to be accessed during method execution on such objects, or if the objects are to be created and discarded on a usual basis, performance-wise, Singletons will most likely be a faster alternative.

In this context, let me demonstrate my personal approach to implementing a Singleton:

public class Singleton
{
	public static const instance : Singleton = new Singleton ();
	public static function Singleton ()
	{
		if ( instance ) throw new Error ( "Already instantiated." );
	}
}

My trick looks like an exploit and a generally terrible idea (now how could a constant change its value?), but works perfectly fine AND avoids the need for the additional overhead from a getInstace () method call and from accessing a private static var to return the instance.

At least some loose coupling please

Static vars and methods, shared state among instances, and Singletons are almost equally deadly to loose coupling. In all of those cases, typing and access issues hinder substitution of the class in question in code variations or upgrades.

The above is completely true, unless one decides to take the Singleton pattern a bit beyond what it usually looks like and to add a layer of abstraction:

public class AbstractSingleton
{
	private static var instance : AbstractSingleton;
	public static function getInstance () : AbstractSingleton
	{
		if ( !instance ) throw new Error ( "Not instantiated." );
		return instance;
	}
	public function AbstractSingleton ()
	{
		if ( instance ) throw new Error ( "Already instantiated." );
		instance = this;
	}
	public function abstractMethod ( ... ) : *
	{
		//	to be overriden.
	}
	...
}

If used as intended this should do the trick. One could probably do a few things to strengthen the implementation, preventing instantiation of the abstract class, even adding some sort of auto-instantiation try-catch trick for the child classes, and so on and so forth. What’s important however is that this ‘abstract’ Singleton pseudo-pattern provides freedom in chosing which concrete object to instantiate at app start, and that’s already quite a gain in terms of loose-coupling.

Singletons can be rather healthy in a UI context

Again, Singletons are a good thing in the context of gui programming. All voluminous and immutable objects are healthy candidates for becoming part of the global state; a provider for a huge and static bitmap is a great example, also an audio mixer for button noises and ambient loops illustrates the point, for there is an absolute benefit of keeping those globally accessible and limit them to a single instance – there is a guarantee that the underlying bulky resource will be loaded only once in the memory.

Also, when an application relies heavily on client/server interactions, and when these put ui-responsiveness at stake, a globally accessible remoting service, be it static, Singleton or Borg, will enable the programme to centrally cache repetitive interactions’ results.

An edit to my boring conclusion

Instead of my previous empty conclusion, I’ll post someday an example of how one could actually get unmatchable loose coupling with the help of a Singleton registry for services.

Bookmark and Share

Vector.unshift () bug

I find it weird that there has been no big noise about this one already. After wasting enough time on debugging, I figured it was time to google JIRA:

http://bugs.adobe.com/jira/browse/ASC-3630

In brief, Vector unshift () removes elements from the end of the vector while adding what’s to be added at the beggining.

A bug like this makes me so sad. Maybe because the typed array was such an anticipated feature of FP10, and because this is such a simple, stupid and brutally overlooked bug. I was thinking, the problem is listed as a compiler bug; I’d rather blame it on the Player API. Any opinions?

Anyway, the workaround is as simple as it gets, but is just as ugly:

vectorInstance.splice ( 0, 0, ... );

And you might as well vote for it on JIRA.

Bookmark and Share

Hello world!

Hello there. Over time I got convinced that keeping it all private is so not fun. And now that my modest time-endowment has limited my ability to get stuff out of my brain and onto the net, I was struck by the revelation that sharing my ideas might as well result in someone else doing the hard work for me. So here I am, starting a blog, and you are most welcome to share stuff back.

Well, hello world! As you might have guessed by now, this blog will be about flash and flash-related stuff. Every now and then I will be outputing some thoughts, code and filler in a hope to maybe be of some use and/or inspiration to the other flashers around the place. Also, I have a couple of cool projects that have been shaping up for a while now, and if I do manage to make them reasonably presentable, all will go on googlecode.

These are the good news, now lets begin with the bad.

Bookmark and Share