Title: [202126] trunk/Source/WebCore
- Revision
- 202126
- Author
- [email protected]
- Date
- 2016-06-16 09:32:04 -0700 (Thu, 16 Jun 2016)
Log Message
Avoid some temporary String allocations for common HTTP headers in ResourceResponse::platformLazyInit()
https://bugs.webkit.org/show_bug.cgi?id=158827
Reviewed by Darin Adler.
Add a HTTPHeaderMap::set() overload taking in a CFStringRef. The
implementation has a fast path which gets the internal characters
of the CFStringRef when possible and constructs a StringView for
it in order to call findHTTPHeaderName(). As a result, we avoid
allocating a temporary String when findHTTPHeaderName() succeeds.
This new HTTPHeaderMap::set() overload is called from both the
CF and Cocoa implementations of ResourceResponse::platformLazyInit().
I have confirmed locally on both Mac and iOS that the fast path
is used ~93% of the time. CFStringGetCStringPtr() returns null in
rare cases, causing the regular code path to be used.
* platform/network/HTTPHeaderMap.cpp:
(WebCore::HTTPHeaderMap::set):
* platform/network/HTTPHeaderMap.h:
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (202125 => 202126)
--- trunk/Source/WebCore/ChangeLog 2016-06-16 06:01:47 UTC (rev 202125)
+++ trunk/Source/WebCore/ChangeLog 2016-06-16 16:32:04 UTC (rev 202126)
@@ -1,3 +1,27 @@
+2016-06-16 Chris Dumez <[email protected]>
+
+ Avoid some temporary String allocations for common HTTP headers in ResourceResponse::platformLazyInit()
+ https://bugs.webkit.org/show_bug.cgi?id=158827
+
+ Reviewed by Darin Adler.
+
+ Add a HTTPHeaderMap::set() overload taking in a CFStringRef. The
+ implementation has a fast path which gets the internal characters
+ of the CFStringRef when possible and constructs a StringView for
+ it in order to call findHTTPHeaderName(). As a result, we avoid
+ allocating a temporary String when findHTTPHeaderName() succeeds.
+
+ This new HTTPHeaderMap::set() overload is called from both the
+ CF and Cocoa implementations of ResourceResponse::platformLazyInit().
+
+ I have confirmed locally on both Mac and iOS that the fast path
+ is used ~93% of the time. CFStringGetCStringPtr() returns null in
+ rare cases, causing the regular code path to be used.
+
+ * platform/network/HTTPHeaderMap.cpp:
+ (WebCore::HTTPHeaderMap::set):
+ * platform/network/HTTPHeaderMap.h:
+
2016-06-15 Zalan Bujtas <[email protected]>
Decouple the percent height and positioned descendants maps.
Modified: trunk/Source/WebCore/platform/network/HTTPHeaderMap.cpp (202125 => 202126)
--- trunk/Source/WebCore/platform/network/HTTPHeaderMap.cpp 2016-06-16 06:01:47 UTC (rev 202125)
+++ trunk/Source/WebCore/platform/network/HTTPHeaderMap.cpp 2016-06-16 16:32:04 UTC (rev 202126)
@@ -61,6 +61,26 @@
return m_commonHeaders.get(headerName);
}
+#if USE(CF)
+
+void HTTPHeaderMap::set(CFStringRef name, const String& value)
+{
+ // Fast path: avoid constructing a temporary String in the common header case.
+ if (auto* nameCharacters = CFStringGetCStringPtr(name, kCFStringEncodingASCII)) {
+ unsigned length = CFStringGetLength(name);
+ HTTPHeaderName headerName;
+ if (findHTTPHeaderName(StringView(reinterpret_cast<const LChar*>(nameCharacters), length), headerName))
+ m_commonHeaders.set(headerName, value);
+ else
+ m_uncommonHeaders.set(String(nameCharacters, length), value);
+ return;
+ }
+
+ set(String(name), value);
+}
+
+#endif // USE(CF)
+
void HTTPHeaderMap::set(const String& name, const String& value)
{
HTTPHeaderName headerName;
Modified: trunk/Source/WebCore/platform/network/HTTPHeaderMap.h (202125 => 202126)
--- trunk/Source/WebCore/platform/network/HTTPHeaderMap.h 2016-06-16 06:01:47 UTC (rev 202125)
+++ trunk/Source/WebCore/platform/network/HTTPHeaderMap.h 2016-06-16 16:32:04 UTC (rev 202126)
@@ -131,6 +131,10 @@
WEBCORE_EXPORT bool contains(const String&) const;
bool remove(const String&);
+#if USE(CF)
+ void set(CFStringRef name, const String& value);
+#endif
+
WEBCORE_EXPORT String get(HTTPHeaderName) const;
void set(HTTPHeaderName, const String& value);
void add(HTTPHeaderName, const String& value);
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
