Bug 239314

Summary: Use [AtomString] where appropriate in IDL files for performance
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: BindingsAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: ashvayka, calvaris, cdumez, changseok, cmarcelo, darin, dino, eric.carlson, esprehn+autocc, ews-watchlist, fmalita, glenn, gyuyoung.kim, jer.noble, kangil.han, kondapallykalyan, mifenton, pdr, philipj, sabouhallawa, sam, schenney, sergio, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch none

Chris Dumez
Reported 2022-04-13 17:02:03 PDT
Use [AtomString] where appropriate in IDL files for performance. I added [AtomString] on the IDL side whenever our C++ implementation uses AtomString. Without this, the generated bindings code will generate a String, which will then get atomized once passed to our implementation. This means we're doing unnecessary String allocations in cases where the AtomString is already in the AtomStringTable.
Attachments
Patch (53.80 KB, patch)
2022-04-13 17:03 PDT, Chris Dumez
no flags
Patch (53.72 KB, patch)
2022-04-13 17:12 PDT, Chris Dumez
no flags
Patch (53.72 KB, patch)
2022-04-13 17:14 PDT, Chris Dumez
no flags
Patch (53.69 KB, patch)
2022-04-13 18:46 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2022-04-13 17:03:49 PDT
Chris Dumez
Comment 2 2022-04-13 17:06:51 PDT
Note that in some cases, we may be able to use [RequiresExistingAtomString] for even better performance. However, I didn't do that in this patch because this is less mechanical and requires closer inspection. I'll follow up as needed.
Alexey Shvayka
Comment 3 2022-04-13 17:10:50 PDT
Comment on attachment 457575 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=457575&action=review Nice! > Source/WebCore/dom/Document.idl:61 > + [NewObject, ImplementedAs=createElementForBindings] Element createElement([AtomString] DOMString localName); // FIXME: missing options parameter. unrelated nit: we might want to remove this FIXME as `options` parameter is part of customised built-ins API which we won't implement. > Source/WebCore/dom/Document.idl:62 > + [NewObject] Element createElementNS([AtomString] DOMString? namespaceURI, [AtomString] DOMString qualifiedName); // FIXME: missing options parameter. ditto
Chris Dumez
Comment 4 2022-04-13 17:12:53 PDT
Chris Dumez
Comment 5 2022-04-13 17:14:29 PDT
Darin Adler
Comment 6 2022-04-13 18:05:23 PDT
Looking forward to the [RequiresExistingAtomString] follow-up too!
Darin Adler
Comment 7 2022-04-13 18:09:13 PDT
Comment on attachment 457577 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=457577&action=review > Source/WebCore/ChangeLog:9 > + Use [AtomString] where appropriate in IDL files for performance. I added [AtomString] on the > + IDL side whenever our C++ implementation uses AtomString. I remember a while back that we thought that some day we might be able to use template cleverness to get the bindings generation to do this automatically based on the type of the function and make the keyword a no-op (and then remove it). But in the mean time, and in case we never manage to figure out how to do that, it’s great to use it the way it was intended. > Source/WebCore/html/HTMLInputElement.idl:59 > + [CEReactions=NotNeeded] attribute [AtomString] DOMString type; // readonly dropped as part of DOM level 2 Wow that comment is *old*, and sure doesn't seem to add much value. But you’re so close to committing, please don’t worry about it.
Chris Dumez
Comment 8 2022-04-13 18:46:44 PDT
EWS
Comment 9 2022-04-13 20:56:19 PDT
Committed r292854 (249625@main): <https://commits.webkit.org/249625@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 457584 [details].
Radar WebKit Bug Importer
Comment 10 2022-04-13 20:57:15 PDT
Chris Dumez
Comment 11 2022-04-14 07:11:51 PDT
Confirmed 0.6% progression on Speedometer on Apple Silicon (neutral on Intel) via A/B bots.
Note You need to log in before you can comment on or make changes to this bug.