[PATCH] D122251: [lit] Use sharding for GoogleTest format

Thu Mar 24 09:20:48 PDT 2022

ychen added a comment.

In D122251#3405396 <https://reviews.llvm.org/D122251#3405396>, @probinson wrote:

>> My suspicion is that most peopke just run check-llvm or check-clang, which includes the regular lit tests, and therefore already ends up with things split across he available cores.
>
> Yes, but.
>
> The way lit works now, it runs each unittest program //once per test function// (plus one, an initial run to retrieve the list of test functions without actually running them).  If a unittest has 500 test functions, lit will run the unittest program 500 times, running one test function each time.  The total number of test functions is some thousands, across all unittest programs.  Even on Linux, the process-creation overhead adds up.  Yes, all those processes are distributed across the available cores, but you're still talking many thousands of processes.
>
> By taking advantage of gtest's sharding feature, within each test program we essentially divide the total number of tests-per-program by the number of cores, and run each test program once per core.  So, the number of processes created goes from (number-of-test-functions-across-all-unittest-programs) to (number-of-cores X number-of-test-programs).  Actually in some cases fewer, because there are a handful of unittest programs that have a very small number of test functions, but for ballparking this is the right calculation.  @ychen can correct me if I'm misunderstanding what's going on.
>
> I believe he tried running each unittest program exactly once, but some of them take significant time, and the net wall-time reduction wasn't as good.  gtest's sharding seemed like a good compromise.

Thanks for the explanation, Paul. That's exactly where the performance gain comes from. I've updated the patch description to explain this.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122251/new/

https://reviews.llvm.org/D122251