[webkit-reviews] review granted: [Bug 239356] Leverage StringView in more places to avoid some String allocations : [Attachment 457653] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Apr 15 15:35:52 PDT 2022


Darin Adler <darin at apple.com> has granted Chris Dumez <cdumez at apple.com>'s
request for review:
Bug 239356: Leverage StringView in more places to avoid some String allocations
https://bugs.webkit.org/show_bug.cgi?id=239356

Attachment 457653: Patch

https://bugs.webkit.org/attachment.cgi?id=457653&action=review




--- Comment #2 from Darin Adler <darin at apple.com> ---
Comment on attachment 457653
  --> https://bugs.webkit.org/attachment.cgi?id=457653
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=457653&action=review

> Source/JavaScriptCore/inspector/ContentSearchUtilities.cpp:94
> +	       result.append(std::pair { lineNumber, line.toString() });

I guess we do need the explicit std::pair; I would omit it if we could.

> Source/WebCore/Modules/fetch/FetchBodyConsumer.cpp:167
> +		   contentType = StringView(header).substring(contentTypeBegin
+ contentTypePrefixLength, contentTypeEnd - contentTypeBegin -
contentTypePrefixLength).stripLeadingAndTrailingMatchedCharacters(isHTTPSpace).
toString();

Is there a very-common case where the header string happens to have nothing
that need to be trimmed, no "\r\n", no spaces? I ask because that is the case
will become *less* efficient, now copying the String.

I wish switching to StringView didn’t make the
stripLeadingAndTrailingHTTPSpaces() function call *so* much longer
stripLeadingAndTrailingMatchedCharacters(isHTTPSpace). On reflection, seems
unnecessarily to have "matched characters" in that function name.

>
Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCRtpTransceiverBackend.cpp
:94
> +    rtcCodec.name = StringView(codec.mimeType).substring(6).utf8().data();

Since we are setting a std::string here it would be better if CString knew how
to convert to std::string without writing .data(), which makes the code look
unnecessarily dangerous, although it’s actually correct and fine. Kind of
annoying that we need both CString and std::string in WebKit. Longer term, I
wonder how many unique great things CString has; maybe we can drop it and
switch to std::string. It uses our faster malloc, but otherwise seems to have
no significantly different features from std::string.

> Source/WebCore/html/HTMLMapElement.cpp:103
>	   m_name = mapName;

WTFMove(mapName)

> Source/WebCore/page/Location.cpp:202
> +    if (!hash.isEmpty() && hash[0] == '#')

We have startsWith(UChar) function for cases like this.

> Source/WebCore/page/UserContentURLPattern.h:37
> +    UserContentURLPattern(StringView pattern)

Should we add explicit?

> Source/WebCore/page/UserContentURLPattern.h:38
>      : m_matchSubdomains(false)

Normally we indent.

> Source/WebCore/platform/network/HTTPParsers.cpp:681
>      // FIXME: The rest of this should use StringView.

Does this comment still make sense?


More information about the webkit-reviews mailing list