comment

Test.hs

@@ -165,9 +165,8 @@ ingredients =
 
 tests :: Bool -> Bool -> TestOptions -> TestTree
 tests crippledfilesystem adjustedbranchok opts = 
-	testGroup "Tests" $ properties 
+	testGroup "Tests" $
-		: withTestMode remotetestmode Nothing testRemotes
+		map (\(d, te) -> withTestMode te (Just initTests) (unitTests d)) testmodes
-		: map (\(d, te) -> withTestMode te (Just initTests) (unitTests d)) testmodes
   where
 	testmodes = catMaybes
 		[ canadjust ("v8 adjusted unlocked branch", (testMode opts (RepoVersion 8)) { adjustedUnlockedBranch = True })

doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_7_e11ae8ba6dd6e6c53891db954d28bfff._comment

@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-03-10T17:58:07Z"
+ content="""
+I tried as an experiment, opening 5 terminals, and running each of the 5
+main groups of tests in parallel manually, each command in a different
+directory:
+
+	git-annex test -p Tests.QuickCheck
+	git-annex test -p Tests.Remote
+	git-annex test -p 'Tests.Unit Tests v8 locked'
+	git-annex test -p 'Tests.Unit Tests v8 unlocked'
+	git-annex test -p 'Tests.Unit Tests v8 adjusted unlocked branch'
+
+They took, respectively, 34, 58, 159, 154, and 220 seconds. Compared to a
+sequential runtime of 444 seconds, this shows it can be sped up well by
+parallelism at least in some cases. Seems likely that splitting up the
+slower blocks further and having 8 groups of tests could make it faster yet.
+
+@yoh, it would be interesting if you could try this on the NFS system and
+see if it speeds it up enough.
+
+---
+
+Tasty does not seem to have a way for parallel forks of the test program
+to report back their status in a way that will be combined together. That
+does seem like something that could perhaps be added to it in a nice clean
+way. 
+
+But, a quick hack is also possible: Have git-annex test fork off one child
+process per each of these groups, and serialize the output. Using
+--color=always when at the console and using concurrent-output to stream
+one of the currently running tests while buffering the rest for later
+display should make this almost indistinguishable from the "right" way.
+Would also need to detect some tasty options and fall back to running it
+normally.
+
+This approach would avoid the problem I hit on the `paralleltest` branch of
+needing to rewrite all the testing code to not run chdired into the repo
+in order to make it able to be run in parallel. That would be a lot of
+work, and would also make it harder to write new tests, since it would be
+easy to make a mistake that caused a test to write outside the test
+repo.
+"""]]