Look how Javascript/CSS3 has moved to the forefront, developers are implementing what flash could do a few years back, but are improving it with semantics and readability. Taking on some of the frailties of Flash (screen readability, fallbacks and other browser implementation issues), don’t get me wrong, it’s still not perfect, but it’s better than some of Flash’s attempts.

I know that there is only a limited amount of resources to implement some of the things developers want, but it seems that they’re not thinking about the broader picture. The company has spent quite a long time implementing the iOS packaging tool for Flash for example. It’s a great little tool, but probably underused considering it’s possible potential. Why do I talk about this, well it turns out that the way the packaging tool works is that it provides away to compile your ActionScript3 code via the LLVM into AVM code. It now turns from a JIT compiled language to AOT compiled language with some issues currently that you can’t have multiple swfs with code in them. This missed opportunity here is that LLVM can have many backend outputs, Adobe only implemented/used one backend and that’s targeting ARM (for iOS). It would be that much of a stretch of imagination to implement a different backend, C/C++/Java (the list continues). So instead of seeing ActionScript as a dead end language with no possible road a head long term (unlike haXe) there could have been a possibility where your ActionScript code could run natively on any platform with the speed of C/C++ (hand written code would obviously be much faster that this version, but it would be faster than running on the AVM!).

Imagine the possibilities, super fast code with the ease of developing with ActionScript… shame it’s never going to happen!

View the source code

AS3-Mixins
I’ve been fortunate to have some free time recently (no idea how or where from!), but I’ve managed to get AS3-Mixins to a stable enough state so that it can be used without it break everywhere. There are a few notable improvements over the first initial creation of the project. It’s gone through a massive re-factor, with the aim to improve the speed of mixin creation at startup. Most of the work has also been looking into improving memory consumption and I spent a lot of time caching bytecode and types from flemit and the mixins project. There is still a bit to do in this area, but it’s a lot more efficient that it’s ever been.

I’ve also added the ability for method overloading from a super class, added the ability to use a mixin in a MixinFactoryPool and tons more. This was mainly aimed at the creation of say tiles in a game, so at the start of a level you can create a series of titles/enemies/etc and reuse them without worrying about how to store them or reuse them. It’s a strongly type factory so it knows what mixin belongs to which pools. There is even a debug helper class which you can use to find out how healthy the MixinFactoryPools are i.e. you can monitor how full the pools are and when they’re about to be grow because the pools will be exhausted. All very useful for development.

AS3-DOM
Another project I’ve started (told you I’ve got some spare time!) is the creation of a DOM system in AS3. With the aim to provide a very easy selection tool for user interfaces (or anything else you can thing of using it with). It’s basically in it’s infancy, but it’s going to be something like xpath for AS3. It’s not going to be the same as xpath, as I’ve not got the time nor the inclination to write every single xpath rule and it would take far too long and I’m sure you could get paid for doing that! One added bonus is that the xpath selection can actually work on the DisplayObject list. The down side is you have to convert the DisplayObject list to the DOM. I may look at away to make a better adapter for this, but for now a help function should suffice.

You can view all of this at my github repo

1. You know when something needs to listen to a Signal
2. You should know how many times your registering to said Signal

I’m more interested in number 2 for now. As the application is ironed out over time, it makes me wonder why we’ve got this extra functionality of allowing multiple listeners to registered to a Signal, when only one suffices. I’ve never been a fan of hooking on to direct callbacks, mainly for the reason that you don’t know what is coming through as the arguments and the added bonus of reading the documentation every time. I’m more interested in self documenting code, not that I’m against documentation! I just want to be able at a glance to understand what the code does (where possible of course).

I had thought about implementing a SingleSignal. The whole purpose of this is to provide away to have a one listener at a time callback. The SingleSignal had to satisfy the following:

1. Only register one listener at a time
2. Notify the developer if they tried to register more than one listener
3. Be faster than the default Signal, as we’ve not got the over head of the linked list and Dictionary
4. Use less memory than the default Signal

It didn’t take me long to implement the functionality of the SingleSignal, as I already had the excellent work of Robert Penner and Joa Ebert to start from. The current implementation is in my github repo. I’ve also created some unit tests to help improve the robustness and prevent errors slipping through.

The last thing I did was verify the performance using the existing performance testing in the repo. Here are the results from a release Flash Player (10.1r85.3) on a mac running 10.6.2:

AddOncePerformance
Note: All tests min time was 0ms for all.

	DeluxeSignal	Signal	SingleSignal
Frames per second (fps):	49fps	60fps	60fps
Memory used:	6mb	6mb	4mb
Max time:	8ms	7ms	4ms

RemovePerformance
Note: All tests ran at 60fps and the min time was 0ms for all.

	DeluxeSignal	Signal	SingleSignal
Memory used:	6mb	6mb	4mb
Max time:	6ms	6ms	4ms

There you have it. It’s up to 33% faster, which won’t be that noticiable, depends on how many addOnce or add and dispatches you’re doing. It also uses 2mb less, which is a good improvement overall. So if you know what the restrictions are of your application and you know you’re going to add one listener and you want to use less memory then a SingleSignal might be for you…

EDIT: slight refractor to make the article more concise.

One thing has struck me of late and that is; we do have really fast operational codes in the language, but other than haXe and Adobe Alchemy not much is taking advantage of it. You can of course try and use TDSI from Joa Ebert, but why should we have to optimise something after we’ve written it? This should be either standard from the language or the compiler.

So what is this really about?
This is about wanting to code without thinking about optimising the basics, you don’t hear of C/C++/C#/Java developers talking about trying to squeeze every ounce of power from the language every time they code something. I’m not saying you shouldn’t optimise, what I am saying is that as a platform it always seems like we’re starting with a handicap.
I want the fasting language for the platform and have all the features for the language. I really like method overloading from Java. I know the AVM2 doesn’t support it by default, but that doesn’t stop you from implementing in some way. A perfect example of this is type parameters (generics) of the Vector class, which I really like from Java and HaXe, but why is it not default on all objects. The compiler checks what your implementing and the aligns it to correct compound types.

Now why can’t a language do this for method overloading, by simply changing the method signature to something else at compile time.

1
2
3
4
5
6
7
8

function method(name:String) : void
{
}
function method(name:String, age:int):void
{
}
method('fred');
method('jim', 24);

This would be translated to the following:

1
2
3
4
5
6
7
8

function method_StringVoid(name:String) : void
{
}
function method_StringIntVoid(name:String, age:int):void
{
}
method_StringVoid('fred');
method_StringIntVoid('jim', 24);

The reason for the curious method signature is to enable something to call the method if it’s not directly know i.e. external swf file etc.

Also why is the fastest int, not used automatically? To use the fastest int, you have to delve into opcodes, which seems extraordinary as you’re actually saying to your developers “we do have this really fast player, but you’re not allowed to use it”. It would be great if a language just used the fastest int and not require the developer to jump into another language (C/C++/haXe).

So now we know we have to do it, what are the best ways to do it. I was running some tests last night and I was actually surprised that I didn’t know this, because it’s obvious.

I made a test which just loops through a for loop attempting to cast various items or the iterator. It’s fairly explanatory, just run the for loops multiple times until you get a big enough delta between beforeTime and the current time to make any sense.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

const NUM_ITERATIONS : int = 1000000;
var i : int = 0;
var beforeTime : int;
 
var element : IElement = ElementFactory.create();
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item0 : Element = Element(element);
}
trace("\tCast method (Class(instance)): " + (getTimer()-beforeTime));
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item1 : Element = element as Element;
}
trace("\tCast method (instance as Class): " + (getTimer()-beforeTime));
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item2 : int = int(i);
}
trace("\tCast method (int(instance)): " + (getTimer()-beforeTime));
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item3 : int = i as int;
}
trace("\tCast method (instance as int): " + (getTimer()-beforeTime));
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item4 : String = String(i);
}
trace("\tCast method (String(instance)): " + (getTimer()-beforeTime));
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item5 : String = i as String;
}
trace("\tCast method (instance as String): " + (getTimer()-beforeTime));
 
beforeTime = getTimer();
for(i=0; i<= NUM_ITERATIONS; ++i)
{
var item6 : String = i.toString();
}
trace("\tCast method (instance.toString()): " + (getTimer()-beforeTime));

So the results:

Cast method (Class(instance)): 6
Cast method (instance as Class): 75
Cast method (int(instance)): 3
Cast method (instance as int): 61
Cast method (String(instance)): 407
Cast method (instance as String): 67
Cast method (instance.toString()): 478

So what does this mean?

To keep it short. Don’t cast to another type, so don’t go from int to String, use ‘as’. Don’t use the toString() method for casting a int to a string, it’s very costly.

This is the important bit: Only if you know what the instance is it safe to do a cast and make sure you don’t use ‘as’. So if you know it’s an Element because of the IElement interface or because of a way to quickly test it (enum class which you define), then use type conversion.

Casting is expensive if you do it wrong, so make sure you do it correctly.

Note:
I tested this with the latest Flash Player 10.1 b3, so this could all change. I’ve not tested with old Flash Players because I’ve got better things to do! Also test with the normal release and not the debugger, I can not emphasis that enough!

Update:
This (i as String) would equal null, I should of checked this.