Summary: | Speed up the apply method of functions by special-casing array and 'arguments' objects | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Cameron Zwarich (cpst) <zwarich> | ||||
Component: | JavaScriptCore | Assignee: | Sam Weinig <sam> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | darin | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 20813 | ||||||
Attachments: |
|
Description
Cameron Zwarich (cpst)
2008-09-21 20:49:54 PDT
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
|