WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
160338
Reduce the number of ResourceRequest copies in DocumentThreadableLoader
https://bugs.webkit.org/show_bug.cgi?id=160338
Summary
Reduce the number of ResourceRequest copies in DocumentThreadableLoader
youenn fablet
Reported
2016-07-29 05:55:39 PDT
DocumentThreadableLoader is making several ResourceRequest copies. We should try to reduce the number of copies.
Attachments
Patch
(40.57 KB, patch)
2016-07-29 06:07 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Patch for landing
(40.70 KB, patch)
2016-07-31 23:34 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
youenn fablet
Comment 1
2016-07-29 06:07:31 PDT
Created
attachment 284860
[details]
Patch
Darin Adler
Comment 2
2016-07-31 21:13:09 PDT
Comment on
attachment 284860
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=284860&action=review
Not sure if the comments about copies are all that helpful unless we have a concrete idea of how to cut down on the copying. How much does this cut down on copying? Did you run some test and count how many times we made copies?
> Source/WebCore/loader/DocumentLoader.cpp:1514 > + CachedResourceRequest cachedResourceRequest(ResourceRequest(request), mainResourceLoadOptions);
Is this needed? Do we get some kind of compiler warning if you don’t explicitly copy it like this?
> Source/WebCore/loader/DocumentThreadableLoader.cpp:250 > + // FIXME: Can we find a way to remove that copy?
Grammatically this should be "this copy".
> Source/WebCore/loader/MediaResourceLoader.cpp:68 > + // FIXME: We should try to remove the copy of request ehwn crearing cacheRequest.
Typo: "ehwn".
> Source/WebCore/loader/ThreadableLoader.cpp:61 > +RefPtr<ThreadableLoader> ThreadableLoader::create(ScriptExecutionContext* context, ThreadableLoaderClient* client, ResourceRequest&& request, const ThreadableLoaderOptions& options)
Interesting to note that both client and context should be references here and I think the result should be a Ref, not a RefPtr.
> Source/WebCore/loader/ThreadableLoader.cpp:72 > +void ThreadableLoader::loadResourceSynchronously(ScriptExecutionContext* context, ResourceRequest&& request, ThreadableLoaderClient& client, const ThreadableLoaderOptions& options)
And context should be a reference here.
youenn fablet
Comment 3
2016-07-31 23:34:14 PDT
Created
attachment 284986
[details]
Patch for landing
WebKit Commit Bot
Comment 4
2016-08-01 00:03:53 PDT
Comment on
attachment 284986
[details]
Patch for landing Clearing flags on attachment: 284986 Committed
r203971
: <
http://trac.webkit.org/changeset/203971
>
WebKit Commit Bot
Comment 5
2016-08-01 00:03:57 PDT
All reviewed patches have been landed. Closing bug.
youenn fablet
Comment 6
2016-08-01 03:40:21 PDT
(In reply to
comment #2
)
> Comment on
attachment 284860
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=284860&action=review
> > Not sure if the comments about copies are all that helpful unless we have a > concrete idea of how to cut down on the copying.
I removed the one for DTL. For MediaResourceLoader, this should be doable.
> How much does this cut down on copying? Did you run some test and count how > many times we made copies?
I did not the counting, this patch comes from other patch discussions on fetch API we had Alex and I. Fetch algorithm requires one request cloning to replay it if needed (redirections, authentication...). We probably need 1 or 2 more for caching purposes. Ideally, we should not do may copies. But we are also making copies because we are doing changes to the request at various places. We should try to reduce these places.
> > Source/WebCore/loader/DocumentLoader.cpp:1514 > > + CachedResourceRequest cachedResourceRequest(ResourceRequest(request), mainResourceLoadOptions); > > Is this needed? Do we get some kind of compiler warning if you don’t > explicitly copy it like this?
request is a ResourceRequest& so we will get a compilation error.
> > Source/WebCore/loader/DocumentThreadableLoader.cpp:250 > > + // FIXME: Can we find a way to remove that copy? > > Grammatically this should be "this copy".
OK. I removed it since it might be difficult to fix that.
> > Source/WebCore/loader/MediaResourceLoader.cpp:68 > > + // FIXME: We should try to remove the copy of request ehwn crearing cacheRequest. > > Typo: "ehwn".
OK. I kept this one since it should be ok to fix it.
> > Source/WebCore/loader/ThreadableLoader.cpp:61 > > +RefPtr<ThreadableLoader> ThreadableLoader::create(ScriptExecutionContext* context, ThreadableLoaderClient* client, ResourceRequest&& request, const ThreadableLoaderOptions& options) > > Interesting to note that both client and context should be references here > and I think the result should be a Ref, not a RefPtr. > > > Source/WebCore/loader/ThreadableLoader.cpp:72 > > +void ThreadableLoader::loadResourceSynchronously(ScriptExecutionContext* context, ResourceRequest&& request, ThreadableLoaderClient& client, const ThreadableLoaderOptions& options) > > And context should be a reference here.
I'll try to do this refactoring.
youenn fablet
Comment 7
2016-08-01 08:15:21 PDT
> > > Source/WebCore/loader/ThreadableLoader.cpp:61 > > > +RefPtr<ThreadableLoader> ThreadableLoader::create(ScriptExecutionContext* context, ThreadableLoaderClient* client, ResourceRequest&& request, const ThreadableLoaderOptions& options) > > > > Interesting to note that both client and context should be references here > > and I think the result should be a Ref, not a RefPtr. > > > > > Source/WebCore/loader/ThreadableLoader.cpp:72 > > > +void ThreadableLoader::loadResourceSynchronously(ScriptExecutionContext* context, ResourceRequest&& request, ThreadableLoaderClient& client, const ThreadableLoaderOptions& options) > > > > And context should be a reference here. > > I'll try to do this refactoring.
Patch for
bug 160404
includes this refactoring.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug