One of the reasons the test procedure in Stylesheets/Test2/ is dramatically faster than the one in Stylesheets/Test/ is that it is, by default, run in parallel.[1,2] You can also ask the make command to run multiple jobs at once. The switches that control this are --jobs= and --output-sync=. I just tried an experiment, comparing how long it took to run make vs make --jobs=7 --output-sync=lines. (I chose 7 because my system has 8 threads, and I wanted to have some CPU available. What little I have found on the web seems to suggest I may as well go ahead and use 8.) The result was faster, although not even close to 7 times faster: down to 03:32 from 04:36. I compared the output of the 2 commands, and they were identical. On GNU/Linux, at least, the nproc command will tell you how many threads are available. Thus using the command $ make --jobs=`nproc 2>/dev/null || echo 1` -Oline seems to make sense to me. (-O is shorthand for --output-sync=.) It is also possible to get the Makefile to do that on its own. My first thought is that might not be such a good idea, because you may want to run with --jobs=1 in order to force error messages into the right order. (I.e., in case -Oline wasn’t good enough.) I ran the experiment again, this time using --jobs=8 and getting screen captures of the process monitor roughly 40 s after the make command started.[3] The timing results were very similar (down to 03:36 from 04:36), but the order of output lines was different. (Same output; i.e., they were identical after sorting and removing timestamps.) So I think anyone running the Stylesheets test process would do well to use the --jobs switch. You could use any of * -j 8 # if you know you have 8 threads, e.g. * --jobs=`nproc` # if you know the nproc command works on your system * -j `nproc 2> /dev/null || echo 1` # if there is a chance nproc fails, so it defaults to '1' Martina — could you either update the notes we have about updating P5 subset, or remind me where they are and I will? Thanks. Notes [1] ant test runs them in parallel; if you want them in series (likely because the order of messages was confusing when run in parallel) use ant testSeries. [2] There are other reasons, like it is written to be less redundant, and the JVM is only spun up once, rather than once for every test. [3] For evidence as to why --jobs makes make faster, see https://bauman.zapto.org/~syd/temp/4TEICouncil/Screenshot_of_make_process_mo... and https://bauman.zapto.org/~syd/temp/4TEICouncil/Screenshot_of_make_-j_process...