Changes between Version 6 and Version 7 of JavaScript performance improvement ideas


Ignore:
Timestamp:
Oct 24, 2007, 10:38:11 PM (17 years ago)
Author:
eric@webkit.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • JavaScript performance improvement ideas

    v6 v7  
    22
    33 * Geoff is working on: Local variable lookup optimization.
    4  * Oliver is working on: Split nodes with switch statements into more classes.
    5  * Darin is working on: ???
    6  * Maciej is working on: ???
    7  * Eric is working on: speeding up KJSCHECKEXCEPTIONSTATE by making a single per-Interpreter/ExecState "somethign bad happened" flag that covers both exceptions and out of memory.
    84
    95'''Some ideas gathered over time:
    106'''
    11  * 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.
    127
    138 * 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.
    … …  
    2722 * 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.
    2823
    29  * 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.
    30 
    3124 * 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.
    3225