Whitelist a subset of tests to be ran on run-perf-tests by default

• Component: Tools / Tests
• Status: NEW ---

[Ryosuke Niwa]

Right now, we run all tests in PerformanceTests by default but this isn't really helpful because some tests generate results with really high variance while others test really specific feature of the browser that it's not worth running as regression tests.

By whitelisting tests that are known to be good indicative of WebKit performance, we can start using these tests to see if a patch cause a real regression or not, paving our way to eventually add pref. EWS bots.

[Eric Seidel (no email)]

Huzzah!

[Zoltan Horvath]

Sounds reasonable. It would be good to check out the used code coverage after we have the whitelist.

[Ryosuke Niwa]

What should be the criteria for a test to be whitelisted?

[Stephanie Lewis]

When calculating a tests value I usually look at reproducibility, coverage/sensitivity, external interest, and length of time to run/difficulty to set up.  If a test's results are not consistent then tracking it's progress creates a burden as opposed to being helpful.  If a test is testing some obscure technologies or doesn't pick up major regressions in what it does test it may not be valuable.  Tests that are run by the media externally are good to keep an eye on.  Length of time to run may not matter here, but if a test breaks a lot if may also impose a burden.

I think a good first step would be figuring out which tests have less than a 2% difference over a significant number of runs of the same source and go from there.

[Ryosuke Niwa]

(In reply to comment #4)
> When calculating a tests value I usually look at reproducibility, coverage/sensitivity, external interest, and length of time to run/difficulty to set up.  If a test's results are not consistent then tracking it's progress creates a burden as opposed to being helpful.  If a test is testing some obscure technologies or doesn't pick up major regressions in what it does test it may not be valuable.  Tests that are run by the media externally are good to keep an eye on.  Length of time to run may not matter here, but if a test breaks a lot if may also impose a burden.

That sounds sensible... except that

> I think a good first step would be figuring out which tests have less than a 2% difference over a significant number of runs of the same source and go from there.

Almost all tests have more than 2% variance :( We should probably fix https://bugs.webkit.org/show_bug.cgi?id=97510 first then.