• I saw that many jsfiles have super short content, and then lots of sibling files.
  • Eg. jstests/core/index contains files like indexN.js where N is 1...13, and a...u, and all of their content is very small.
• There is startup overhead to running each file... I found running a batch of 10 empty JS files takes about 38 sec locally and serially, meaning 3-4 sec of overhead for each.
  • We can parallelize this with -jN, and that 3-4 sec is amortized in wallclock time, not sure if compute time would still matter
• If all of the indexN content lived in the same file, structured with mochalite, we could shave off the overhead from 24ish files, saving ~1m15s of raw overhead.
• That's from these files in jscore, which are hit in required variants, but they're also included in 100+ suites (buildscripts/resmoke.py find-suites jstests/core/index/index1.js | wc ), of which some subset being included in 95 tasks, 62 variants, and ~1600 different task-variant combos. I'm not sure what the effective/practical multiplier means for that just yet, but it's a good order of magnitude.
• It'd be a slog to determine test intent, ie "does index3.js do anything novel that index7.js isn't already doing?". But restructuring test points/files is very mechanical and could have some quick wins.

Repro steps:

bazel build install-dist-test

touch mytest.js

# just one
buildscripts/resmoke.py run mytest.js

# 10 in serial
buildscripts/resmoke.py run \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js

# 10 in parallel
buildscripts/resmoke.py run \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  mytest.js \
  -j10