[webkit-reviews] review granted: [Bug 238162] String literals with _str suffix should not need to do strlen() at runtime : [Attachment 455332] Patch
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Mar 22 07:43:59 PDT 2022
Darin Adler <darin at apple.com> has granted Chris Dumez <cdumez at apple.com>'s
request for review:
Bug 238162: String literals with _str suffix should not need to do strlen() at
runtime
https://bugs.webkit.org/show_bug.cgi?id=238162
Attachment 455332: Patch
https://bugs.webkit.org/attachment.cgi?id=455332&action=review
--- Comment #5 from Darin Adler <darin at apple.com> ---
Comment on attachment 455332
--> https://bugs.webkit.org/attachment.cgi?id=455332
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=455332&action=review
So unclear to me when to use _s vs. _str — please write down a guideline for
future use somewhere. Maybe we’ll even want to rename one or both so it’s more
obvious when one is right vs. the other.
If ""_s was smaller code than ""_str then you’d want to decide based on how
likely a code path was perhaps? I personally don’t like having a choice when
it’s not obvious which is better, and there are so often choices where you
could use "", ""_s, or ""_str.
For example, does a string literal argument to makeString compile into a code
sequence that involves call to strlen? Or does that get constant-folded? What
about if you use ""_s or ""_str instead of just ""?
> Source/WTF/ChangeLog:9
> + it could trigger calls to strlen() at run time to figure out the
length of the string. This was unforunate
Typo in unfortunate
> Source/WTF/ChangeLog:14
> + This patch also adopts the ""_str operator in more places so they
can leverage the optimization.
Is this a measurable speedup? Is it a measurable code size increase or
decrease?
> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:2538
> + return $useAtomString ? "AtomString(${defaultValue},
AtomString::ConstructFromLiteral)" : "${defaultValue}_str";
Looks like you need to rebase the bindings test results because of these
changes to CodeGeneratorJS.pm.
More information about the webkit-reviews
mailing list