WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Chris Dumez
Comment 1
2022-04-16 20:41:38 PDT
Created
attachment 457763
[details]
Patch
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
<
rdar://problem/91903893
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug