| | 1 | ''Ideas for new optimizations for SquirrelFish'' |
| | 2 | |
| | 3 | * reduce cost of calling with too many arguments - at least one SunSpider test does this a lot. Some possibilities: |
| | 4 | * Allocate a few extra parameter slows for every function, so just a few extra is cheap |
| | 5 | * 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. |
| | 6 | |
| | 7 | * Make variants of instructions that can read directly from the constant pool, to avoid all the "load" insns you get when dealing with constants. |
| | 8 | |
| | 9 | * Atomize constant strings, so any given string is only in the constant pool once. |
| | 10 | |
| | 11 | * Maybe sorting opcode implementations by frequency of use would make things faster. |
| | 12 | |
| | 13 | '''Larger ideas:''' |
| | 14 | |
| | 15 | * 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. |
| | 16 | |
| | 17 | * 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. |
| | 18 | |
| | 19 | * 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 awy. |
| | 20 | |
