Some ideas gathered over time:

• Make a JSGlobalObject class that needs to be used for an Interpreter's global object, and make Window subclass it. This would rRemove time spent in InterpreterMap hashtable, which should be a 1-2% improvement by itself. Various code needs to get from a global scope object back to the corresponding interpreter. If the global object was a specific JSObject subclass, it could store an interpreter to the global object directly. This change might also allow other simplifications.

• 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.

• Make the static lookup.h-style hashtables power-of-two sized to save the cost of integer divide. Another possible optimization is to store the static property names as UTF-16 arrays instead of strings.

• 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.

• Scalable Array implementation so that JS arrays don't just "fall off the cliff" when they get over the size threshold. One possible idea is that you expand the storage if items are added close to the current end of the storage. Another possibility is using a more general sparse array implementation.

• 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.

• Micro-optimize double --> JSImmediate and JSImmmediate --> int conversions.

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