'''Ideas for new optimizations for SquirrelFish''' * reduce cost of calling with too many arguments - at least one SunSpider test does this a lot. Some possibilities: * Allocate a few extra parameter slows for every function, so just a few extra is cheap * If we can limit or remove the functionality of randomFunc.arguments, then for functions that do not themselves use arguments we could just overwrite the extra args. * Make variants of instructions that can read directly from the constant pool, to avoid all the "load" insns you get when dealing with constants. * Atomize constant strings, so any given string is only in the constant pool once. * Maybe sorting opcode implementations by frequency of use would make things faster. '''Larger ideas:''' * Store primitive types directly in registers, along with type info. Tamarin's 64 bit NaN encoding trick may work well here. We could have both instructions that statically infer a specific type, and dynamic type inference which uses instructions that think a particular type is more likely and optimize for that case with checks. * Explicit vtables. Right now we use C++ virtual methods for polymorphic behavior of JS types. An explicit vtable could store per-type pure data as well as functions, turning some things that are currently virtual method calls into simple pointer derefs. * Better codegen framework. We don't have a great way to pick from one of several instructions, using a "tile matching" algorithm may be a good way. This could enable super-instructions, type-specialized instructions, and handling of the fact that you may want different codegen in value, condition and void contexts. '''Analysis of SunSpider tests that show little improvement''' 3d-morph: Suffering from missing cross-scope access optimization and DontDelete global optimization (9.4% deep time in resolve()). Probably suffering from lack of static type inference (lots of time in jsNumberCell, JSImmediate, NumberImp::toNumber, etc. access-nbody: Major factor seems to be lack of type specialization (lots of time in number-related stuff). date-format-tofte: Lots of time spent in parsing and code generation for eval. Can codegen itself be optimized? Also lots of time in makeFunction(), a big chunk of this is making the empty prototype for the function object, as well as setting the special properties (prototype, constructor, length), perhaps those coudl be handled in a smarter way. Also function call overhead for FuncDeclNode::makeFunction itself. Perhaps it should be inlined. Also it is suspicious that call overhead for makeFunction would be a bottleneck, is it getting called more often than it should? date-format-xparb: