Next Adobe needs to improve its Virtual Machine.
Can Adobe work with hardware vendors like ARM to incorporate the improved AVM into the hardware just like Jazelle?

Flash is a wonderful platform to work with. :)
–
Jaseem V V

I know that saying bad performance is good is a bold statement. But think about it. You do not have to reinvent the wheel all the time. For a lot of stuff performance is good enough. Java however which was suffering from “poor” performance as well made a jump with a high cost. The VM startup and warmup time. I think that this is one of the biggest reasons why noone uses Java applets any more. Starting an applet takes still so much time. One effort of JavaFX is to reduce that time of course. But that was one tradeoff for better performance.
We can improve the performance of Flash applications a lot by improving the compiler without touching the VM at all. Isn’t that fantastic? And we can get much better performance by fixing simple (and complex) things in the Flash Player. This is great; stagnation is not great. And we have suffered from stagnation in the past two years at least. 2010 will be (hopefully) the year of Flash Player performance improvements.

I also definitely disagree that poor performances is a good thing. Whatever the performances of a language/VM, you will have to find tricks to push it further. Having good performances from the beginning is better than having to reinvent the wheel in order to build a car…

Events are just a way to implement asynchronous notifications, but are actually not very elegant since you need to deal with all the listeners while actors offer a way to write async code as much easily as you would write synchronous code. Look at Scala actors for an example ;)

Looks like this project only started this February and I think something like this is long overdue. That said, because it’s new it unfortunately won’t be ready until next release cycle (CS6? Flex 5?) that we see any gains, as I don’t imagine there’s time to add any improvements to Flash CS5 or Flex 4.

Currently am playing with different ideas of writing my custom Event managers that have different function for adding and cleaning groups of listeners. For example like that:
addEventListener(listenerOwner, listenerFunction, dispatcher, eventType)

Then I have methods like cleanOwnerEvents(owner) which removes all listeners from all objects to which owner had added listeners. Or cleanDispatcherEvents(dispatcher) that cleans all event listeners that were added to this dispatcher. But those two add opposite problem of removal of listener that should have not been removed in some other context this code does not know of. Well for that I have cleanOwnerEventsOnDispatcher(owner,disaptcher) which removes all events added by owner from dispatcher. Also I have methods that take in array of owners, dispatchers, event types and listeners in different ways. Makes code a lot smaller and easier to manage but it is still not perfect. But that’s something I learned trough recent years to use. New developers will use original functions, and they will make mistakes, and I will be looking for a bug that was caused by that.

There are other problems with Flash Events too though they are less problematic, like they are little bit not versatile in some cases and they are not really that fast.

On other hand I think only language I was using much in recent years was C#(though a lot less then AS3) and their events model is not really that better. It probably performs better and has less problems in some cases but brings their own set of compromises and tricky situations as far as I can tell.

Having an STM is great but you would have to decide very careful how it is implemented. Blocking or non blocking, pure or not?

Also it is easy to write unresponsive AS, despite there being no blocking features. The lack of concurrency adds to the problems of that unresponsiveness. If I load a large file and want to parse it in some way, I can’t do it in a background thread. So to parse the file without impacting performance, I have to construct an asynchronous multi-stage parsing scheme, which greatly increases the chances of bugs.

If/ when the flash player supports multiple threads, I don’t want to have to use events, actors, rendezvous etc. I want transactional memory. Forget functions as first class objects, closures and real properties as advantages over Java: transactional memory would really give AS a genuine advantage.

This post was mentioned on Twitter by joa: The Advantage Of ActionScript http://bit.ly/dxiGUr...