I've been thinking about something recently, I guess this one's a big thing and hopefully somebody will go and implement this very soon.
A lot of work is always done on the code optimization side of things, and recently this has hit the ActionScript world; most notably (imho) with haxe and TAAS - both of these things have a lot of optimizations improving the compile process, which means our code ultimately runs faster :) inlining, code reduction, dead code elimination, flow optimization etc.
Ultimately, the fastest compiled script will always be a flat set of vm operations with none of that expensive method calling and instantiation, and lets remember that OO is pretty much a syntax we use to develop, haxe makes it clear with its common syntax which compiles to multiple vm targets.
So, here's the background question - why do our actionscript classes compile to compiled classes?, all the code from those nested called methods could be factored right the way back in to one big method, and a single class, then heavily optimized - imagine the speed gains.
Thinking further, implementing doesn't appear too hard - i mean all your going to need to do is essentially copy the code from one method and place it in the calling method at the correct position(s); any duplicate code introduced would be offset easily by the amount of code cut out by removing all those un-needed classes and methods - further the unused classes and methods would be lost; and the final chunks of code could be optimized to hell and back.
The only problem i can see is that we need compiled classes to distribute or pull in remotely sometimes, which is why I'd propose a simple "Service" interface (or suchlike) the point of which is that any class marked as a service class (or gateway?) would keep its class structure and public methods.. after all everything behind the public methods is of no concern to any other part of the system.
If you consider a flex application for example, or that class which uses circa 5% of all the large libs included in the final compiled script.. not to mention the additional optimizations that could be made on the big blocks of code in each method!
So that's it, Flat Packing - the ultimate optimization?
ps: quite sure this applies to most OO languages not just actionscript ( haxe guys will agree I'm sure (I hope) ).
Regards!
That's definitely the *theoretically* fastest way to do things. I remember back in the day when folks would "compile" bitmaps down to explicit instructions instead of copying data into memory.
The problem, beyond the one you mention of interoperability between SWFs, is code bloat. Inlining everything would generate a *huge* amount of extra code. I would expect your SWF to be 10x or even 100x bigger, and not significantly faster. Remember the 80/20 rule and how it would apply: you'll bloat out 80% of your code to 10x or 100x its size without any noticeable difference.
The brilliance of what TAAS does (and any really good compiler) is doing what you describe selectively and smartly, making trade-offs that yield actual benefits as opposed to dumbly inlining everything.
I fully comprehend the code bloat issue, in all honesty i think that only 20% of the original code would cause the bloat - further i think this approach would lead to better results, rather than optimizing what the programmer has done (which is always inherintly flawed) monolith the entire app by inlining everything, then un-inline the bloat - quite sure this approach would lead to improved results; when used with opcode reduction and optimization techniques such as taas and in-part haxe :)
Inlining has diminishing returns (assuming your call performance isn't painfully bad) due to issues like memory caching, instruction decoding, etc.
What you want is to inline your inner loops as much as possible, maximizing opportunities for instruction level parallelism, and not sweat the rest.
In addition because AS3 is dynamic, there are a lot of situations where the compiler lacks the knowledge needed to inline, even if you are using strict typing.
TBH I think the biggest bottleneck for AS3 right now is memory - cost of allocation - and the conflict between convenient syntax and what helps the compiler.
In general, AS3 is a young language. It needs years of serious work to mature. Languages like C# and Java are a lot more mature and have addressed these problems in pretty powerful ways.
There are two big BUT's, maybe another one related to the flash player:
1. Recursion is very, very hard to handle. This would become, or some bunch of jumps, or some methods still apart.
2. Your swf becomes big. Very big. And the loading time too. This is a common know trade-off for optimization by caching. But with big, I mean very very big. OO-projects contain many, many links between functions, causing problem 1 too.
(3.) Can flash handle such a long code run...
I agree this is interesting. I think one advantage haxe has over TAAS is that is has more information to begin with, and it has some extra type info - eg Int vs Float, and typed arrays.
One thing with functions is that the can be virtual - ie, the runtime does not know exactly which function will be called at runtime so it must leave it in as a symbolic reference.
Obviously the code bloat could be done on the client end, keeping the swfs a constant size - but cpu cache issues make make small code run faster than large code.
I think a good way of thinking about this is factorizing in mathematics. First you multiply out the brackets, then you group like terms, and cancel some out, and then extract factors to form a new, simpler, expression.
We all lurve smarter compilers - well worth thinking about.
we have 4 scenarios here:
the way things currently work (afaik) - take the language syntax, turn it in to vm opcodes (mxmlc)
the way things work better - take the language syntax, turn it in to vm opcodes and optimize on the way (haxe)
the bloated way - take the language syntax, inline everything, turn it in to vm opcodes
the proposed way - take the language syntax, inline everything, turn it in to vm opcodes, optimize, identify repeat code and factor in to functions, optimize again
thus your not making syntax work on a vm, your effectively using the compiler to rewrite your application perfectly for the target vm.
follow?