Just out of curiosity, I used the "--slowest" option to see which tests were
slowest in a debug build. On my fairly-fast Mac Pro the tests took 14 minutes
overall (849.76s), and these were the ten slowest tests:
9.57 secs: editing/selection/move-left-right.html
7.64 secs: editing/selection/extend-selection.html
6.91 secs: websocket/tests/frame-lengths.html
6.67 secs: http/tests/cache/subresource-expiration.html
5.41 secs: fast/js/toString-and-valueOf-override.html
5.13 secs: http/tests/xmlhttprequest/small-chunks-response-text.html
5.11 secs: http/tests/navigation/slowtimerredirect-basic.html
5.06 secs: http/tests/navigation/slowmetaredirect-basic.html
3.94 secs: http/tests/misc/acid3.html
3.64 secs: fast/workers/worker-cloneport.html
Out of 11955 tests, these are 0.08% of the tests and they take 6.95% of the
time. To me that means we might be able to speed things up quite a bit by
tackling the slowest tests.
But making the test engine run tests on multiple cores in parallel could
probably speed things up a lot more.
And I’m sure that release builds will be quite different.
It was not long ago when the entire run-webkit-tests process completed in 1
minute. 14 minutes is significantly different, and I’m wondering if there’s
something we can do.
I have nothing specific to suggest, but wanted to share this data.
-- Darin
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
