We use a specialized path in String.replace for lambdas of the form 'return b[a]'. This is pretty important for ss-string-unpack-code, but when the lambda has not yet been compiled this pattern matching doesn't work and we do the generic thing. Subsequent replace() calls with the lambda will work, but even the first time around costs quite a bit in this benchmark --- running with lazy parsing is about 20% slower than without. The attached patch fixes this oversight, and with it we get about the same scores on the benchmark whether lazy parsing is enabled or not.

It looks like you've inverted the meaning of LambdaIsGetElem? You return true when it's not a JSOP_GETALIASEDVAR.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #1) > It looks like you've inverted the meaning of LambdaIsGetElem? You return > true when it's not a JSOP_GETALIASEDVAR. Adding the getOrCreateScript call means this method is now fallible so its return value is a success code. Whether it actually found a match is indicated through the (new) outparam pobj.

Comment on attachment 763265 [details] [diff] [review] patch Heh, any time ss-string-unpack-code we should just assume LambdaIsGetElem needs to be updated.