Changes between Version 19 and Version 20 of JavaScript performance improvement ideas
- Timestamp:
- Nov 7, 2007 9:52:12 AM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
JavaScript performance improvement ideas
v19 v20 6 6 * Darin is working on: Making missed array-index lookups faster (not making Identifiers) and misc. PCRE speedups. 7 7 * 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 9 9 10 '''Some ideas gathered over time: 11 ''' 10 '''Some ideas gathered over time:''' 12 11 13 12 * 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. … … 21 20 * 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). 22 21 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 24 23 25 24 * 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 … … 27 26 * 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. 28 27 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 30 29 31 30 * Where possible, combine toPrimitive() conversion with later toString().
