perf(core): schedule static mutants last to avoid transition reloads#6137
Open
lo1tuma wants to merge 1 commit into
Open
perf(core): schedule static mutants last to avoid transition reloads#6137lo1tuma wants to merge 1 commit into
lo1tuma wants to merge 1 commit into
Conversation
Static mutants force a test-runner environment reload. Plans were sorted only within each buffered batch, so static and non-static plans interleaved and every interleaving forced an extra reload on the non-static mutant that followed a static one. Ordering the whole run non-reload-first and reload (static) last removes those transition reloads, while non-static mutants still stream and overlap with checking as before. The effect is measurable with the experimental performance report (stryker-mutator#6136): totals.reload drops toward the static-mutant count, which on static-heavy suites using full-restart runners (mocha, jasmine, karma, tap) cuts wall time.
lo1tuma
force-pushed
the
schedule-static-mutants-last
branch
from
July 17, 2026 13:37
fec7026 to
40faa83
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Static mutants force a test-runner environment reload (a full worker restart on mocha, jasmine, karma and tap). Today the run plans are sorted only within each buffered micro-batch, so static and non-static plans interleave across batches. Each interleaving forces an extra reload on the non-static mutant that happens to follow a static one, on top of the reload the static mutant itself needs.
This orders the whole run non-reload-first and reload (static) last instead of per batch, so static plans no longer interleave with the rest and nothing pays a transition reload. Non-static mutants still stream and overlap with the checker as before; only the static tail is deferred.
I found this with the experimental performance report from #6136, and the two PRs are independent (apply both to reproduce). Measured as a controlled back-to-back A/B on an idle machine on a large mocha + TypeScript project (same config, 2558 mutants run):
The reload-count reduction is deterministic (the transition reloads are eliminated, so the count now matches the static-mutant count). The wall-time figures are single-run and this suite is noisy, so treat them as directional; the win grows with the share of static mutants and is specific to full-restart runners (mocha, jasmine, karma, tap).