On Tue, Nov 26, 2024 at 6:27 AM Timofei Zhakov <t...@chemodax.net> wrote:
> On Tue, Nov 26, 2024 at 11:11 AM Daniel Sahlberg < > daniel.l.sahlb...@gmail.com> wrote: > >> Den mån 25 nov. 2024 kl 15:10 skrev <rin...@apache.org>: >> >>> ### This makes configure step too slow if the option is enabled. Can we >>> ### prevent regeneration of the tests list if these files haven't been >>> ### changed? Probably, I'll look at this a bit more, if we consider this >>> ### as an issue. >>> ### >>> ### However, when I measured the time taken to configure CMake, I got >>> just >>> ### 6.5s with the option enabled, against 0.8s when it has been >>> disabled... >>> >> >> This looks great. I think the slowdown is more than acceptable since: >> - It is off by default so it won't slowdown a non-user. >> - It adds a lot of value to those who use it. >> >> If you find an easy way to recover this lost time it'd be nice but I >> think other things should have higher priority. >> > > Going a bit off-topic: > > This makes it take a lot of time to run the tests, especially with CMake, > which doesn't support parallel execution. For example, in my environment, > it takes 6.4 min to run only merge_tests.py (it includes 146 subtests). For > instance, I am measuring it with cmake and EXPAND_TESTS option enabled. > > However, it's so complicated to implement the parallel execution, because > the Subversion test-suite needs to create repositories and working copies > for sharing between the tests. Usually, it does it when tests are beginning > to run, like when `make check` has been invoked. > > So, if a few tests are running at the same time, they will try to create > one working-copy over another, causing a failure. > > To try it out, run the tests using `ctest -j 16` command (it will fail). > > > -- > Timofei Zhakov > The first idea that comes to my mind is to somehow uniquify the test repos and working copies, perhaps by putting them in a subdirectory named for the test, so (just picking something by random) merge test #123 might have its test data in ....../merge_tests/123/.... Then if multiple tests run simultaneously they shouldn't bother each other. Of course, how that would happen is another matter. Perhaps the test driver could record which test it is about to run and the repo and wc creation could use that information? Cheers, Nathan
