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.
<rdar://problem/5353293>
Created attachment 15643 [details] patch that actually makes it faster than pre-regression
Comment on attachment 15643 [details] patch that actually makes it faster than pre-regression r=me, with the comments from IRC
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.
Created attachment 15645 [details] oops, caused some test regressions; fix