Create a short writeup: "How to write efficient AS3"

ASSIGNED
Unassigned

Status

Tamarin
Documentation
P2
normal
ASSIGNED
6 years ago
6 years ago

People

(Reporter: Lars T Hansen, Unassigned)

Tracking

unspecified
Q2 12 - Cyril

Details

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

6 years ago
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.
(Reporter)

Comment 2

6 years ago
(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).
(Reporter)

Comment 4

6 years ago
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.)
(Reporter)

Updated

6 years ago
Assignee: lhansen → nobody
You need to log in before you can comment on or make changes to this bug.