I noticed this when running the full unittest suite locally, but it should also benefit the unittests in the commit queue and patch builds. The db_repl_test binary, and to a lesser extent, util_test, take much longer to run than the rest. When running a debug build locally on 40 cores, I still normally spend several minutes at the end waiting for just db_repl_test.

Using timings from a recent commit queue patch shows:

Looking into the suites shows just a few that run much longer than the others:

Looking more closely at RandomizedIdempotencyTest shows that CheckUpdateSequencesAreIdempotent takes ~3 secs, and CheckUpdateSequencesAreIdempotentV2 takes the remaining ~26 secs:

2020-09-16T12:52:35.435Z I  TEST     23063   [main] "Running","attr":{"suite":"RandomizedIdempotencyTest"}
2020-09-16T12:52:35.435Z I  TEST     23059   [main] "Running","attr":{"test":"CheckUpdateSequencesAreIdempotent","rep":1,"reps":1}
...
2020-09-16T12:52:38.925Z I  TEST     23059   [main] "Running","attr":{"test":"CheckUpdateSequencesAreIdempotentV2","rep":1,"reps":1}
...
2020-09-16T12:53:04.803Z I  TEST     23060   [main] "Done running tests"

So it might be good to split at least this test (CheckUpdateSequencesAreIdempotentV2) or suite (RandomizedIdempotencyTest), and maybe some of the others, into separate binaries, so that they can better parallelize onto multiple cores.

(Sending this to SDP, since the ticket is primarily about improving overall (parallel) unittest runtime by avoiding individual long-running tests/suites/binaries. But it could of course be redirected to Replication to fix these particular ones.)