[[!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.
"""]]
