Bug 187671

Summary: Reduce size of NetworkLoadMetrics and therefore ResourceResponse
Product: WebKit Reporter: Alex Christensen <achristensen>
Component: New BugsAssignee: Alex Christensen <achristensen>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, cgarcia, commit-queue, darin, dbates, ews-watchlist, joepeck, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch
none
Patch none

Description Alex Christensen 2018-07-13 16:33:56 PDT
Reduce size of NetworkLoadMetrics and therefore ResourceResponse
Comment 1 Alex Christensen 2018-07-13 16:36:53 PDT
Created attachment 345001 [details]
Patch
Comment 2 Alex Christensen 2018-07-13 17:29:55 PDT
Created attachment 345008 [details]
Patch
Comment 3 Darin Adler 2018-07-14 06:56:03 PDT
Comment on attachment 345008 [details]
Patch

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

Concept here is fine but std::numeric_limits<unit64_t>::max() is probably better than writing -1.

Also if we really want to optimize the size of this it seems strange we really need 64 bits for something like header size. There must be much smaller practical limits for the sizes of various things here. And we could store headers in a sorted vector instead of a map and save a *lot* more space.

I am also concerned that this leaves nothing behind to remind us to keep this small. I could easily imagine someone showing up soon with a “cleanup” patch to make this use std::optional and we are not even leaving a comment behind to prevent that.

> Source/WebCore/inspector/agents/InspectorNetworkAgent.cpp:246
> +    if (networkLoadMetrics.requestHeaderBytesSent != -1ull)

-1ull does not make sense. -1 is not an unsigned number. Can we find a correct way to write this?
Comment 4 Chris Dumez 2018-07-14 08:14:04 PDT
(In reply to Darin Adler from comment #3)
> Comment on attachment 345008 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=345008&action=review
> 
> Concept here is fine but std::numeric_limits<unit64_t>::max() is probably
> better than writing -1.
> 
> Also if we really want to optimize the size of this it seems strange we
> really need 64 bits for something like header size. There must be much
> smaller practical limits for the sizes of various things here. And we could
> store headers in a sorted vector instead of a map and save a *lot* more
> space.

HTTPHeaderMap is based on Vector nowadays already, not HashMap.

> 
> I am also concerned that this leaves nothing behind to remind us to keep
> this small. I could easily imagine someone showing up soon with a “cleanup”
> patch to make this use std::optional and we are not even leaving a comment
> behind to prevent that.
> 
> > Source/WebCore/inspector/agents/InspectorNetworkAgent.cpp:246
> > +    if (networkLoadMetrics.requestHeaderBytesSent != -1ull)
> 
> -1ull does not make sense. -1 is not an unsigned number. Can we find a
> correct way to write this?
Comment 5 Alex Christensen 2018-07-16 12:10:05 PDT
Created attachment 345105 [details]
Patch
Comment 6 Alex Christensen 2018-07-16 12:19:12 PDT
Created attachment 345107 [details]
Patch
Comment 7 Alex Christensen 2018-07-16 12:26:23 PDT
Created attachment 345109 [details]
Patch
Comment 8 Alex Christensen 2018-07-16 12:55:46 PDT
Comment on attachment 345109 [details]
Patch

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

> Source/WebCore/platform/network/NetworkLoadMetrics.h:171
> +    uint32_t requestHeaderBytesSent;
> +    uint32_t responseHeaderBytesReceived;

I used uint32_t for the header bytes.
Comment 9 WebKit Commit Bot 2018-07-16 13:23:59 PDT
Comment on attachment 345109 [details]
Patch

Clearing flags on attachment: 345109

Committed r233863: <https://trac.webkit.org/changeset/233863>
Comment 10 WebKit Commit Bot 2018-07-16 13:24:01 PDT
All reviewed patches have been landed.  Closing bug.
Comment 11 Radar WebKit Bug Importer 2018-07-16 13:24:24 PDT
<rdar://problem/42253400>