Currently, functionProtoFuncApply() accesses the arguments via numerical indices using the generic path for lookup. We should really fix this. Sam has a patch to do this, so I'm assigning this to him.
Created attachment 23643 [details] patch
Comment on attachment 23643 [details] patch Taking this out of the review queue. I am afraid that this might break RegExpMatchesArray.
Comment on attachment 23643 [details] patch As we discussed on IRC, this code seems like it would break with the RegExpMatchesArray, since that array is lazily filled when a property is retrieved.
Should be straightforward to fix it for RegExpMatchesArray one of two ways: 1) Make a call to fill out a RegExpMatchesArray before doing the rest. 2) Do a check for JSArray with the exec->machine()->isJSArray() function that returns false for RegExpMatchesArray and keep a slow case for JSArray derived classes around for RegExpMatchesArray (and maybe WebCore/bridge bindings arrays?)
Comment on attachment 23643 [details] patch Putting this back up for review since it doesn't break RegExpMatchesArray. I have added new test cases for it however and will land them if this gets reviewed.
Comment on attachment 23643 [details] patch If speed really matters for Arguments, then we need to do various checks outside the loops rather than inside, so for example: - We need an entirely separate loop for the Arguments case where there are no deleted arguments. - The loop for the parameters should come first, then a separate loop to handle arguments. r=me
Landed in r36779. There is still more work to be done to speed up Function.apply however.