RESOLVED FIXED Bug 239427
Use AtomString as early as possible when string will eventually get atomized
https://bugs.webkit.org/show_bug.cgi?id=239427
Summary Use AtomString as early as possible when string will eventually get atomized
Chris Dumez
Reported 2022-04-16 20:37:31 PDT
Use AtomString as early as possible when string will eventually get atomized.
Attachments
Patch (53.92 KB, patch)
2022-04-16 20:41 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2022-04-16 20:41:38 PDT
Darin Adler
Comment 2 2022-04-18 09:54:33 PDT
Comment on attachment 457763 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=457763&action=review From bindings we could have AtomString&& instead of const AtomString& for cases where we are taking ownership and want to save some reference count churn. Not sure how important this is to performance, but it is an optimization possibility. > Source/WebCore/svg/SVGLengthValue.cpp:276 > + StringBuilder builder; > + builder.append(m_valueInSpecifiedUnits, lengthTypeToString(m_lengthType)); > + return builder.toAtomString(); We should create makeAtomString for cases like this one. It’s a bit wasteful to use StringBuilder when we know everything up front, and it’s not too hard to write a makeAtomString.
Chris Dumez
Comment 3 2022-04-18 10:01:49 PDT
(In reply to Darin Adler from comment #2) > Comment on attachment 457763 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=457763&action=review > > From bindings we could have AtomString&& instead of const AtomString& for > cases where we are taking ownership and want to save some reference count > churn. Not sure how important this is to performance, but it is an > optimization possibility. Yes, Sam mentioned the same thing on Slack. I'll likely look into this in the near future. > > Source/WebCore/svg/SVGLengthValue.cpp:276 > > + StringBuilder builder; > > + builder.append(m_valueInSpecifiedUnits, lengthTypeToString(m_lengthType)); > > + return builder.toAtomString(); > > We should create makeAtomString for cases like this one. It’s a bit wasteful > to use StringBuilder when we know everything up front, and it’s not too hard > to write a makeAtomString. Let me see how hard it can to write.
Chris Dumez
Comment 4 2022-04-18 10:14:48 PDT
(In reply to Chris Dumez from comment #3) > (In reply to Darin Adler from comment #2) > > Comment on attachment 457763 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=457763&action=review > > > > From bindings we could have AtomString&& instead of const AtomString& for > > cases where we are taking ownership and want to save some reference count > > churn. Not sure how important this is to performance, but it is an > > optimization possibility. > > Yes, Sam mentioned the same thing on Slack. I'll likely look into this in > the near future. > > > > Source/WebCore/svg/SVGLengthValue.cpp:276 > > > + StringBuilder builder; > > > + builder.append(m_valueInSpecifiedUnits, lengthTypeToString(m_lengthType)); > > > + return builder.toAtomString(); > > > > We should create makeAtomString for cases like this one. It’s a bit wasteful > > to use StringBuilder when we know everything up front, and it’s not too hard > > to write a makeAtomString. > > Let me see how hard it can to write. I'll follow-up for this.
Darin Adler
Comment 5 2022-04-18 10:30:22 PDT
(In reply to Chris Dumez from comment #4) > I'll follow-up for this. Basically makeAtomString is really only an optimization for short strings. Once we know the string is short enough we can use an on-stack buffer, build the entire string on the stack, look up the existing StringImpl and allocate a new one only if it’s not already in the AtomString table. For a longer string, since we have to allocate on the heap anyway, I don’t think we can do much better than AtomString(makeString(xxx)), allocating a buffer (a StringImpl, in fact) and then deallocating it if it turns out to be identical to one in the table.
EWS
Comment 6 2022-04-18 10:57:21 PDT
Committed r292960 (249725@main): <https://commits.webkit.org/249725@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 457763 [details].
Radar WebKit Bug Importer
Comment 7 2022-04-18 10:58:13 PDT
Note You need to log in before you can comment on or make changes to this bug.