[webkit-dev] Anyone else having these problems with run-webkit-tests?
dpranke at chromium.org
Mon Mar 24 14:54:53 PDT 2014
On Sun, Mar 23, 2014 at 12:52 PM, Benjamin Poulain <benjamin at webkit.org>wrote:
> Same here :(
> On 3/23/14, 12:15 PM, Darin Adler wrote:
>> When I use run-webkit-tests to run the entire test suite, on a debug
>> build of TOT WebKit, on Mavericks, I’m having the following problems:
>> - Towards the end of the run, the tests run slowly, over a second per
>> test on my 3.5GHz i7 iMac with tons of memory, which is about 10X too slow
>> I think. The sample shows the vast majority of the time is spent in
> Yep. The time from 31k to 33k is a long as from 0 to 31k :(
> - Towards the end of the run, instead of the 8 parallel copies of
>> DumpRenderTree, only 1 copy of DumpRenderTree seems to run. This is running
>> mostly the svg/custom tests.
> I think the problem is we can only run DumpRenderTree in parallel on
> different folders. Toward the end, everything left is one or two slow
The problem is partially that the sharding is folder-at-a-time, partially
that the svg folder is big and slow, and partially that "svg" comes near
the end of the alphabet (i.e., we don't start the big slow directory until
close to the end of run, so there ends up being one big long pole).
At some point we added code to run-webkit-tests to have a list of "slow"
directories that got started towards the beginning. I don't remember if we
did that before or after the Blink fork, but it would be easy to port it
over from Blink if it was after.
There is also the --experimental-fully-parallel flag that you can use,
which shards a test at a time and get you the full parallelization until
the last 8 tests. The downside to this is that you'll probably have a lot
Hope this is useful,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev