Hi, Interesting results. We were discussing the same thing last week. I was somewhat skeptical to the ideal as I am afraid of increased flakyness -- LLDB has hardcoded timeout values in a lot of places, and with increased cpu contention, we might start to see this code failing because the other side was slower than expected.
I have now tried running the test suite with a higher number of threads and it seems it working quite alright, so I think we can try that. I'll watch the buildbots for signs of increased flakyness. FWIW, it did not speed up the tests for me at all, but I guess that's expected, as it ran in 90 seconds even before that, and the limiting factor there probably is the longest test. As for the timeout, I have set the value to 4 minutes, based on the formula: 2 * (number of seconds when I first started noticing flaky tests in the slowest configuration). The slowest configuration here was running the test suite on a debug build of lldb and using debug ToT clang to compile the inferiors (believe it or not, this makes a big difference). So there is still some leeway here, but if you're gonna reduce the default, please make sure it is enough for the slowest test configuration also. For faster configurations you can always override the timeout manually. pl _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev