Bug 119277

Summary: Reduce JSC API static value setter/getter overhead
Product: WebKit Reporter: Yi Shen <max.hong.shen>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, eflews.bot, ggaren, gyuyoung.kim
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
Test case
none
proposal patch
ggaren: review-
avoid to create OpaqueJSString every time
none
add comments to eliminate confusion ggaren: review-, eflews.bot: commit-queue-

Yi Shen
Reported 2013-07-30 14:40:11 PDT
To set/get the static value, JSC APIs always call OpaqueJSString::create() to make a thread-safe string copy and pass it to the setXXX/getXXX function which is implemented by the API client. However, the client's setXXX/getXXX doesn't need to know the property name in most case (because they already know the property name). To reduce the overhead, it would be nice to introduce a new JSPropertyAttribute to allow the client decide whether a property name string copy should be created and passed as a parameter.
Attachments
Test case (541 bytes, text/html)
2013-07-30 14:56 PDT, Yi Shen
no flags
proposal patch (3.99 KB, patch)
2013-07-30 14:59 PDT, Yi Shen
ggaren: review-
avoid to create OpaqueJSString every time (7.29 KB, patch)
2013-07-31 11:28 PDT, Yi Shen
no flags
add comments to eliminate confusion (8.38 KB, patch)
2013-07-31 14:48 PDT, Yi Shen
ggaren: review-
eflews.bot: commit-queue-
Yi Shen
Comment 1 2013-07-30 14:56:58 PDT
Created attachment 207769 [details] Test case
Yi Shen
Comment 2 2013-07-30 14:59:18 PDT
Created attachment 207770 [details] proposal patch
WebKit Commit Bot
Comment 3 2013-07-30 15:00:53 PDT
Attachment 207770 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/JavaScriptCore/API/JSCallbackObjectFunctions.h', u'Source/JavaScriptCore/API/JSObjectRef.h', u'Source/JavaScriptCore/ChangeLog']" exit_code: 1 Source/JavaScriptCore/API/JSObjectRef.h:55: enum members should use InterCaps with an initial capital letter. [readability/enum_casing] [4] Source/JavaScriptCore/API/JSObjectRef.h:56: enum members should use InterCaps with an initial capital letter. [readability/enum_casing] [4] Total errors found: 2 in 3 files If any of these errors are false positives, please file a bug against check-webkit-style.
Yi Shen
Comment 4 2013-07-30 15:16:31 PDT
(In reply to comment #3) > Attachment 207770 [details] did not pass style-queue: > > Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/JavaScriptCore/API/JSCallbackObjectFunctions.h', u'Source/JavaScriptCore/API/JSObjectRef.h', u'Source/JavaScriptCore/ChangeLog']" exit_code: 1 > Source/JavaScriptCore/API/JSObjectRef.h:55: enum members should use InterCaps with an initial capital letter. [readability/enum_casing] [4] > Source/JavaScriptCore/API/JSObjectRef.h:56: enum members should use InterCaps with an initial capital letter. [readability/enum_casing] [4] > Total errors found: 2 in 3 files > > > If any of these errors are false positives, please file a bug against check-webkit-style. The existing & new added JSPropertyAttribute are not using InterCaps with and initial capital letter, which makes the style checker unhappy. But I think we should keep that.
Yi Shen
Comment 5 2013-07-30 15:16:46 PDT
result(ms) Pass name Don't pass name getter/setter getter/setter 1. 344/321 193/159 2. 375/341 196/159 3. 337/322 193/160 4. 339/317 193/158 5. 342/323 195/159 6. 338/320 194/159 7. 338/322 195/160 8. 341/333 193/159 9. 355/323 195/161 10. 354/337 195/157 ---------------------------------------------------- avg 346/326 194/159
Geoffrey Garen
Comment 6 2013-07-30 17:18:42 PDT
Comment on attachment 207770 [details] proposal patch I don't think we should fix this with a special attribute. What about all our existing clients that don't use the attribute? Let's optimize this path not to call OpaqueJSString::create() every time.
Yi Shen
Comment 7 2013-07-31 11:28:41 PDT
Created attachment 207866 [details] avoid to create OpaqueJSString every time
Yi Shen
Comment 8 2013-07-31 11:30:10 PDT
Thanks for reviewing. I added a new patch based on your comments. (In reply to comment #6) > (From update of attachment 207770 [details]) > I don't think we should fix this with a special attribute. What about all our existing clients that don't use the attribute? > > Let's optimize this path not to call OpaqueJSString::create() every time.
EFL EWS Bot
Comment 9 2013-07-31 12:50:54 PDT
Comment on attachment 207866 [details] avoid to create OpaqueJSString every time Attachment 207866 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/1288847
Geoffrey Garen
Comment 10 2013-07-31 13:19:04 PDT
Comment on attachment 207866 [details] avoid to create OpaqueJSString every time This looks good, but it leaves the code in a bit of a confused state, because now getters build in a propertyNameRef, but setters still call "propertyNameRef = OpaqueJSString::create(name);", and it's not clear why. Can you update setters to match getters as well?
Yi Shen
Comment 11 2013-07-31 14:40:43 PDT
Thanks for reviewing :) The setters call "OpaqueJSString::create()" only if there is a setProperty function defined in the callee JSClass (OpaqueJSClass::setProperty). In this case, the property name is undetermined until the setters was invoked (Actually, user can pass any value as a property name and client's code will determine whether it is valid). One solution to avoid to create OpaqueJSString every time in this case is to use a Map structure, but it will cause memory overhead. For JSClass that doesn't have a setProperty function, the setters search the static values table by property name and call the set function only if it can find. My patch only focus on this case, and has updated setters to match the static value getters. Please check the changes for JSCallbackObject<Parent>::put() and JSCallbackObject<Parent>::putByIndex. (In reply to comment #10) > (From update of attachment 207866 [details]) > This looks good, but it leaves the code in a bit of a confused state, because now getters build in a propertyNameRef, but setters still call "propertyNameRef = OpaqueJSString::create(name);", and it's not clear why. Can you update setters to match getters as well?
Yi Shen
Comment 12 2013-07-31 14:48:35 PDT
Created attachment 207878 [details] add comments to eliminate confusion
EFL EWS Bot
Comment 13 2013-07-31 15:50:51 PDT
Comment on attachment 207878 [details] add comments to eliminate confusion Attachment 207878 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/1300718
Geoffrey Garen
Comment 14 2013-07-31 16:28:46 PDT
Sorry, you were right the first time -- I just misread the code.
Geoffrey Garen
Comment 15 2013-07-31 16:31:01 PDT
Comment on attachment 207866 [details] avoid to create OpaqueJSString every time r=me
Geoffrey Garen
Comment 16 2013-07-31 16:31:21 PDT
Comment on attachment 207878 [details] add comments to eliminate confusion This version isn't necessary.
WebKit Commit Bot
Comment 17 2013-07-31 16:56:12 PDT
Comment on attachment 207866 [details] avoid to create OpaqueJSString every time Clearing flags on attachment: 207866 Committed r153547: <http://trac.webkit.org/changeset/153547>
WebKit Commit Bot
Comment 18 2013-07-31 16:56:15 PDT
All reviewed patches have been landed. Closing bug.
Yi Shen
Comment 19 2013-07-31 16:59:36 PDT
Thank you, Geoffrey :] (In reply to comment #15) > (From update of attachment 207866 [details]) > r=me
Note You need to log in before you can comment on or make changes to this bug.