Bug 20982 – Speed up the apply method of functions by special-casing array and 'arguments' objects

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Cameron Zwarich (cpst)]

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.

[Sam Weinig]

Created attachment 23643 [details]
patch

[Sam Weinig]

Comment on attachment 23643 [details]
patch

Taking this out of the review queue.  I am afraid that this might break RegExpMatchesArray.

[Cameron Zwarich (cpst)]

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.

[Darin Adler]

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?)

[Sam Weinig]

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.

[Darin Adler]

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

[Sam Weinig]

Landed in r36779.  There is still more work to be done to speed up Function.apply however.