I'm thinking of a document of a few pages that we would circulate widely and update occasionally. ("How to make your AS3 code fast" or something.) It would contain high-value advice on how to write fast AS3. It would also contain a pointer to an address to which to provide feedback and complaints about performance. The audience is professional developers. Some things that might go into this document (everything needs vetting for correctness and utility): - Always compile with "-strict -AS3" - Always use type annotations; avoid "*" and "Object" types when you can - Never use Array, use Vector - Vector provides more type information - If you must use Array, always lift the array value into a typed temp before using it - Use methods in classes, do not use top-level functions Obviously my focus is the core language. There may be a few things having to do with effective use of the Flash Player too, I don't know yet. Just getting something out there is better than covering the field completely. I think the document should contain forward-looking ideas only, not hackarounds, so techniques such as object caching to cope with GC overhead are probably not appropriate, or if they are, they should be included with caveats.
Perhaps another thing: - Use concrete data types (eg ByteArray) to type variables when you can, not the interfaces they implement (eg IDataInput), since it's in general much easier for the JIT to optimize for the concrete type.
(In reply to Lars T Hansen from comment #0) > - Use methods in classes, do not use top-level functions That's much too strong. Top-level functions within packages are constant-bound and present in the script traits, and the JIT will early bind them and is in principle able to inline them as they are not overridable. So the rule is: - If you use top-level functions, be sure to place them within packages.
(In reply to Lars T Hansen from comment #2) > (In reply to Lars T Hansen from comment #0) > > > - Use methods in classes, do not use top-level functions > > That's much too strong. Top-level functions within packages are > constant-bound and present in the script traits, and the JIT will early bind > them and is in principle able to inline them as they are not overridable. > So the rule is: > > - If you use top-level functions, be sure to place them within packages. I will want to double-check some of the observations made in Bug 698721 (namely Bug 698721, comment 20 and Bug 698721, comment 23) prior to agreeing with the above assertion. In particular, there may be hidden costs to introducing new top-level functions that we should isolate (and hopefully eliminate).
Never use "arguments", always use "...rest": the latter has cleaner semantics, and is optimized better in the VM. We should include advice on how to use it effectively: always use the rest argument as part of an object reference: rest.length or rest[i], never for the value by itself. In that case, the array object will normally not be allocated at all. (In practice it is safest to stay away from any identifier even called "arguments" because there are some dark corners of the language and VM around the arguments feature, I would not be surprised if a local called "arguments" could trigger the creation of an arguments object. That would be an ASC bug, not a VM bug. It would be good to do some testing here to ensure that this particular piece of advice is not needed.)