[Webkit-unassigned] [Bug 203165] New: First page load after WKWebView init blocks on sync IPC to UIProcess

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=203165

            Bug ID: 203165
           Summary: First page load after WKWebView init blocks on sync
                    IPC to UIProcess
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: nham at apple.com
                CC: beidson at apple.com

The very first page loaded by PLT5 is usually delayed by ~100-150 ms (i.e. time from when we ask the browser to load the URL to the time the first bytes are put on the wire). The reason for this is that WebProcess makes a sync call back to UIProcess, which is in the middle of doing other work, like making more views and then committing a CATransaction. I think this could be more than a test artifact, e.g. opening a URL in a new window seems like it would trigger a similar flow.

PLT5 starts by creating a new browser window, which creates a WKWebView. Among other things, this causes us to take a WebProcess out of the pool and call SetWebsiteDataStore on it, which passes along some parameters like the session ID:

```
bool WebKit::AuxiliaryProcessProxy::send<Messages::WebProcess::SetWebsiteDataStoreParameters>
WebKit::WebProcessProxy::setWebsiteDataStore
WebKit::WebProcessPool::tryTakePrewarmedProcess
WebKit::WebProcessPool::processForRegistrableDomain
WebKit::WebPageProxy::launchProcess
WebKit::WebPageProxy::launchInitialProcessIfNecessary
...
+[BrowserWindowController openEmptyBrowserWindowController]
Safari::PageLoadTestWithChrome::createNewWindow
Safari::PageLoadTest::run
```

The WebProcess responds to this by turning right back around and issuing a sync IPC back to the UIProcess asking for a connection to the NetworkProcess:

```
bool IPC::Connection::sendSync<Messages::WebProcessProxy::GetNetworkProcessConnection>
WebKit::getNetworkProcessConnection
WebKit::WebProcess::ensureNetworkProcessConnection()
void IPC::handleMessage<Messages::WebProcess::SetWebsiteDataStoreParameters, WebKit::WebProcess, void (WebKit::WebProcess::*)(WebKit::WebProcessDataStoreParameters&&)>
IPC::Connection::dispatchMessage
IPC::Connection::dispatchOneIncomingMessage
WTF::RunLoop::performWork
...
WebKit::XPCServiceMain
```

Since the main thread of the UIProcess is busy doing other things (like sending even more messages to WebProcess, building up its view hierarchy, committing a CATransaction, etc.), this sync IPC ends up blocking for 85 ms in the trace that I'm looking at. Importantly, it blocks the WebProcess from processing web page's LoadRequest method:

```
void IPC::handleMessage<Messages::WebPage::LoadRequest, WebKit::WebPage, void (WebKit::WebPage::*)(WebKit::LoadParameters&&)>(IPC::Decoder&, WebKit::WebPage*, void (WebKit::WebPage::*)(WebKit::LoadParameters&&))
IPC::MessageReceiverMap::dispatchMessage
WebKit::WebProcess::didReceiveMessage
IPC::Connection::dispatchMessage
IPC::Connection::dispatchOneIncomingMessage
WTF::RunLoop::performWork
...
WebKit::XPCServiceMain(int, char const**)
```

WebProcess still seems to wait on UIProcess before it actually begins loading the main resource (since it waits for a policy decision from the UIProcess before doing so), but I think that removing the sync IPC will allow for better parallelization between UIProcess and WebProcess init during first-page-load scenarios and win us back some tens of ms.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191018/f30edae1/attachment.html>