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.
Created attachment 299539 [details] patch
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.
https://trac.webkit.org/changeset/211068
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.
Oops!
Did that in https://trac.webkit.org/r211076
<rdar://problem/30306314>