On Mon, Apr 6, 2009 at 6:57 PM, David Levin <[email protected]> wrote:
> Release tests on a dual core now take about half the time they used to.
>> There's still a lot of room for improvement and I'm a bit burnt out on this
>> stuff, so if anyone is willing to help that would be much appreciated. Here
>> are the remaining obvious things we could do to make a significant
>> performance improvement:
>>
>> 1. Test and turn on parallelizing for Debug builds
>> 2. Get 4 or 8 core webkit buildbots
>> 3. Shard LayoutTests/fast and LayoutTests/http. Right now, in order to
>> reduce test flakiness, we bucket tests by directory and run all those tests
>> in the same process (thanks to dlevin for this idea!). The problem is that
>> we're left with two very large buckets that can be further broken down. The
>> work of breaking them down further is trivial (just add the directory names
>> to a list in run_webkit_tests.py), the bigger problem is that some flakiness
>> starts to appear in the fast/http tests when we break them down further. So,
>> we need people to figure out what the source of the flakiness is and deal
>> with it appropriately.
>>
>
> For #3, an alternative may be to sort "http" tests to be first and don't
> break it down further. ("http" is less than one quarter of the time on OSX
> at least, so you can still scale up to quad core.)
>
We already kind of do this. We sort by the number of tests in the bucket. It
probably makes sense to special-case the http tests since each http test
takes so much longer than the other tests. The http tests would still be the
bottleneck even if we ran them first. Regardless, I'll make a change
tomorrow to run them first though.
> Also, I think fast (and dom) can be broken down into the 1st sub dir level
> without increased flakiness.
>
Yeah, I tried it on my quad-core mac and dual-core Windows machines and
there was a bit of flakiness. Although, maybe that right thing to do here is
just to bucket it and add the flaky tests to the test_expectations.txt file.
My only concern is that the flaky test isn't the failing test, but another
test that some how affects the failing test, in which case, this approach
would not work.
Ojan
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
