Maintain ordering when doing speculative loads

• Component: Page Loading
• Status: RESOLVED FIXED

[Antti Koivisto]

Currently we randomize the ordering of speculative loads because they are serialized as a hash map. It would be better to load in the same order as the requests were originally issued as that is likely to match the order the document needs them.

[Antti Koivisto]

Created attachment 299539 [details]
patch

[Chris Dumez]

Comment on attachment 299539 [details]
patch

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

r=me

> Source/WebKit2/NetworkProcess/cache/NetworkCacheSubresourcesEntry.cpp:109
> +    Vector<SubresourceInfo> result;

I think we should reserveInitialCapacity() and uncheckedAppend() since we know there will be at most subresourceLoads.size() items and the common case will be subresourceLoads.size() items.

> Source/WebKit2/NetworkProcess/cache/NetworkCacheSubresourcesEntry.h:49
> +        , m_requestHeaders(request.httpHeaderFields())

It is a bit unfortunate that we are now copying those HashMaps for transient resources too now. I hope this does not show on PLT.

[Antti Koivisto]

https://trac.webkit.org/changeset/211068

[Darin Adler]

Comment on attachment 299539 [details]
patch

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

>> Source/WebKit2/NetworkProcess/cache/NetworkCacheSubresourcesEntry.cpp:109
>> +    Vector<SubresourceInfo> result;
> 
> I think we should reserveInitialCapacity() and uncheckedAppend() since we know there will be at most subresourceLoads.size() items and the common case will be subresourceLoads.size() items.

The patch landed with a call to reserveCapacity/append, but reserveInitialCapacity/uncheckedAppend are more efficient.

[Antti Koivisto]

Oops!

[Antti Koivisto]

Did that in https://trac.webkit.org/r211076

[Radar WebKit Bug Importer]

<rdar://problem/30306314>