1-5% regression in JavaScript performance

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Maciej Stachowiak]

The following revision caused a measurable JS performance regression:

http://trac.webkit.org/projects/webkit/changeset/24287

This results in a 1% slowdown on JS iBench and a 5% slowdown on the "Celtic Kane" JS benchmark. The problem is that we now always walk the scope chain doing variable lookups, which results in extra hashtable traffic and a more complex function.

[Darin Adler]

<rdar://problem/5353293>

[Maciej Stachowiak]

Created attachment 15643 [details]
patch that actually makes it faster than pre-regression

[Darin Adler]

Comment on attachment 15643 [details]
patch that actually makes it faster than pre-regression

r=me, with the comments from IRC

[Cameron Zwarich (cpst)]

Removing the jsString() is in contradiction with section 12.2 of the ECMA spec, which says that variable statements return the name of the identifier as a string. Not that I think this is a sane choice or even useful in a single case, but it's why I copied it in from the other code.

I recently noticed that even with the jsString() there now it won't return the string value if you do something like:

function f() {
  var x = 1;
}

alert(f());

It's worth noting that neither Firefox nor Opera return the string.

[Maciej Stachowiak]

Created attachment 15645 [details]
oops, caused some test regressions; fix