Changes between Version 19 and Version 20 of JavaScript performance improvement ideas


Ignore:
Timestamp:
Nov 7, 2007 9:52:12 AM (15 years ago)
Author:
eric@webkit.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • JavaScript performance improvement ideas

    v19 v20  
    66 * Darin is working on: Making missed array-index lookups faster (not making Identifiers) and misc. PCRE speedups.
    77 * Maciej is working on: eval restrictions, maybe mark stack if I get bored.
    8  * Eric is working on: -
     8 * Eric is working on: evaluteToNumber, and type inferencing
    99
    10 '''Some ideas gathered over time:
    11 '''
     10'''Some ideas gathered over time:'''
    1211
    1312 * 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.
     
    2120 * Constant folding. This could be done purely by the parser, for strings, numbers, even regexps.  Only a couple tests use constants which could be folded (long strings built with +), however none of those do so in a loop (where we would see much benefit).
    2221
    23  * 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.
     22 * 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.  One bug: http://bugs.webkit.org/show_bug.cgi?id=15879
    2423
    2524 * Store static hashtable property names as UTF-16 arrays instead of c-strings for quicker key comparisons.  http://bugs.webkit.org/show_bug.cgi?id=15865
     
    2726 * 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.
    2827
    29  * 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.
     28 * 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.  One bug: http://bugs.webkit.org/show_bug.cgi?id=15884
    3029
    3130 * Where possible, combine toPrimitive() conversion with later toString().