What we're working on:

• Geoff is working on: Optimizing global variable accesss, nested scope, VarDeclNode, etc.
• Oliver is working on: Alternate representations of immediate values.
• Cameron is working on: Not creating ActivationImps when we don't need to.
• Darin is working on: -
• Maciej is working on: eval restrictions, maybe mark stack if I get bored.
• Eric is working on: -

Some ideas gathered over time:

• Avoid creating wrapper objects just to access standard properties and methods of primitive values like strings and numbers. Mainly this is an issue for strings - numbers don't have that many interesting properties or methods. This one is slightly tricky. Ideally we'd call methods without making a wrapper at all, and just code them specially to work on the primitive value, or reuse a single wrapper per type when it's created implicitly for property access. However, there are ways that the implicit wrapper can be captured. Adding nonstandard methods or getters/setters to the prototype will make the implicit wrapper get exposed to arbitrary code, which could put it in a global variable or the like. So to make this work, we would need the wrapper to know that and swap itself out for a new reusable temporary wrapper when a custom property is accessed.

• Have a version of toString conversion that gives a StringImp* instead of a UString, and try to code as much string handling as possible to return the same StringImp if something equal to the original string is getting returned.

• Generational mostly-copying garbage collector. This one is likely to be pretty hard.

• Use bytecode or something similar to make the interpreter non-recursive so it doesn't use so much stack. But the inner loop has to be coded carefully because obvious ways of doing will regress performance instead of speeding it up. (direct threading, subroutine threading, context threading)

• Constant folding. This could be done purely by the parser, for strings, numbers, even regexps.

• Special-case numeric code. If we can prove some values are guaranteed to be numeric, we could evaluate expressions involving them purely using doubles, without converting intermediate values to immediate values or NumberImps at all.

• Store static hashtable property names as UTF-16 arrays instead of c-strings for quicker key comparisons.

• Possibly do all property handling via the regular property map somehow, even native-code implemented properties, to avoid doing the extra lookup in the static hashtable at all.

• Lightweight type inference. A lot of operators take needless virtual calls and branches because they behave differently depending on whether the operands are strings or numbers, etc. A lot of this can be eliminated based on even the most basic knowledge of operand types, which can be inferred based on constants in the code and output types of operators.

• Where possible, combine toPrimitive() conversion with later toString().