On Tue, Nov 26, 2024 at 6:45 AM Nathan Hartman <hartman.nat...@gmail.com> wrote:
> 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? > (hit send too soon) I meant record it in a variable, not on disk obviously or else that information would get clobbered by parallel running tests!! Cheers, > Nathan >
