[Webkit-unassigned] [Bug 70699] New: [WK2][GTK] Each test takes roughly half a second to load

[bugzilla-daemon at webkit.org]

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

           Summary: [WK2][GTK] Each test takes roughly half a second to
                    load
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: zandobersek at gmail.com


When running layout tests for WebKit2, the testing takes considerably longer than when testing for WebKit1. This occurs when running the tests through either ORWT or NRWT.

The problem is that the simple loading of the test file takes 400-600 milliseconds. The loading call is done in TestInvocation::invoke()[1]. I've then traced the problem deep into WebKit2. All the excess time is wasted between when sending the LoadURL message between WebPageProxy::loadURL()[2] in UIProcess and WebPage::loadURL()[3].

Digging deeper, the problem seems to occur when a new message is enqueued and work is scheduled on the run loop in Connection::enqueueIncomingMessage()[4]. But the callback of the source that this call creates and appends to the main context doesn't get called any time soon, even stranger, the messages are still dispatched by a Connection::dispatchMessages function that is still in progress.

I've then put a static counter outside Connection::dispatchMessages and increased it when it was called. When a message was dispatched in this function, I printed it out. I've then ran 69 tests with some tests ensured to fail. (By the way, these tests take ~30 seconds with WKTR and ~7 seconds with DRT.) The output showed that in the seventh test of those 69 (first to fail), the last call to Connection::dispatchMessages before WebPageProxy::loadURL was called was the 392th call since the start of testing. The call to Connection::dispatchMessages that (about half a second later) actually dispatched the LoadURL message was only 68th.

I thought that was strange and hit the ChangeLogs with some grepping, and found bug #62496. Reverting changes made in that commit (r88588), there were some minor changes in behavior - the call to RunLoop::scheduleWork now properly set up the source, which later triggered the callback to Connection::dispatchMessages. While this seemed to be an improvement, the time difference between RunLoop::scheduleWork and Connection::dispatchMessages was still those 400-600 milliseconds.

This seems to be the problem, suggestions/fix warmly welcome!

[1] http://trac.webkit.org/browser/trunk/Tools/WebKitTestRunner/TestInvocation.cpp#L153
[2] http://trac.webkit.org/browser/trunk/Source/WebKit2/UIProcess/WebPageProxy.cpp#L433
[3] http://trac.webkit.org/browser/trunk/Source/WebKit2/WebProcess/WebPage/WebPage.cpp#L530
[4] http://trac.webkit.org/browser/trunk/Source/WebKit2/Platform/CoreIPC/Connection.cpp#L666

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.