RESOLVED FIXED 134560
Buffer CSS and JS resources in network process before sending over to web process
https://bugs.webkit.org/show_bug.cgi?id=134560
Summary Buffer CSS and JS resources in network process before sending over to web pro...
Pratik Solanki
Reported 2014-07-02 14:34:38 PDT
Buffer CSS and JS resources in network process before sending over to web process
Attachments
Patch (7.48 KB, patch)
2014-07-02 14:39 PDT, Pratik Solanki
no flags
Patch (7.01 KB, patch)
2014-07-02 17:39 PDT, Pratik Solanki
ap: review-
Patch (5.91 KB, patch)
2014-07-08 10:56 PDT, Pratik Solanki
koivisto: review+
Patch for bots that will apply cleanly now (5.80 KB, patch)
2014-07-09 17:23 PDT, Pratik Solanki
no flags
Pratik Solanki
Comment 1 2014-07-02 14:39:13 PDT
Pratik Solanki
Comment 2 2014-07-02 14:40:17 PDT
Initial implementation with USE(CFNETWORK) support for iOS. I'm looking into doing this for mac as well.
Brady Eidson
Comment 3 2014-07-02 15:11:14 PDT
Is there actually no advantage to streaming JS and CSS resources as the bytes come in? It seems like the JIT could get started on an incomplete resource, saving time later...?
Pratik Solanki
Comment 4 2014-07-02 17:39:01 PDT
(In reply to comment #3) > Is there actually no advantage to streaming JS and CSS resources as the bytes come in? I don't know if it's possible to start parsing,JITting JS or CSS as the bytes come in. It's certainly not something we do right now. > It seems like the JIT could get started on an incomplete resource, saving time later...? I guess if we start doing that and it proves to be a perf win, then we can disable this optimization.
Pratik Solanki
Comment 5 2014-07-02 17:39:16 PDT
Pratik Solanki
Comment 6 2014-07-02 17:39:55 PDT
Alexey Proskuryakov
Comment 7 2014-07-03 01:41:19 PDT
Comment on attachment 234299 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=234299&action=review Looks like a good idea, assuming that it doesn't break progress events or resource load timing or Web Inspector (which are all too involved for me to assess at the moment, but at least tests pass). > Source/WebKit2/NetworkProcess/NetworkResourceLoader.h:199 > + RefPtr<WebCore::SharedBuffer> m_bufferedData; It seems super unfortunate that sync loads collect the data in SynchronousNetworkLoaderClient object, but all loads have a data member in NetworkResourceLoader. I think that this should be designed in a uniform way, definitely without having multiple instances of the data member.
Antti Koivisto
Comment 8 2014-07-03 02:18:55 PDT
I already had a patch for this in https://bugs.webkit.org/show_bug.cgi?id=132229 also covering image resources.
Alexey Proskuryakov
Comment 9 2014-07-03 02:47:26 PDT
Correct. The problem with that patch was that it coalesced way too much, needlessly and dangerously changing semantics of network loader.
Pratik Solanki
Comment 10 2014-07-03 15:29:18 PDT
Yeah, this one is a bit more targeted and simpler. But the idea is the same.
Pratik Solanki
Comment 11 2014-07-03 15:33:47 PDT
(In reply to comment #7) > (From update of attachment 234299 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=234299&action=review > > Looks like a good idea, assuming that it doesn't break progress events or resource load timing or Web Inspector (which are all too involved for me to assess at the moment, but at least tests pass). > > > Source/WebKit2/NetworkProcess/NetworkResourceLoader.h:199 > > + RefPtr<WebCore::SharedBuffer> m_bufferedData; > > It seems super unfortunate that sync loads collect the data in SynchronousNetworkLoaderClient object, but all loads have a data member in NetworkResourceLoader. > > I think that this should be designed in a uniform way, definitely without having multiple instances of the data member. Good idea. I can definitely merge them and make the code more efficient for SynchronousLoaderClient.
Pratik Solanki
Comment 13 2014-07-09 17:23:51 PDT
Created attachment 234673 [details] Patch for bots that will apply cleanly now
Pratik Solanki
Comment 14 2014-07-09 23:14:58 PDT
Antti Koivisto
Comment 15 2014-07-13 07:28:30 PDT
*** Bug 132229 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.