Repository navigation
Improve startup and test-run performance - #3460
Merged
Merged
Conversation
Member
|
@sindresorhus I'm fine with the changes, do you think you could rebase and fix formatting issues? |
Profiling the worker and main processes under load surfaced overhead that scales with the number of test files and events rather than the work the tests actually do. This cuts that overhead substantially: - ~40% faster for many small test files (startup-bound) - ~30% faster for a single file with thousands of tests - ~50% faster for many files run concurrently The gains come from reducing per-worker module loading and per-event main-process work. Changes: - Defer heavy worker dependencies until actually needed. Workers loaded the glob stack (via the provider manager), the line-number parser (acorn) and write-file-atomic eagerly, though plain-JavaScript files with no line-number filter never use them. They now load lazily. - Load Concordance lazily. Concordance and its lodash dependency (~22ms to evaluate) were loaded in every worker via the assertions, test and snapshot modules, and in the main process via error serialization, even though passing simple assertions, plain `t.log` calls, snapshot-free runs and worker-level errors never touch it. A small shared module loads it on first use. This roughly halves the worker module-load tree or assertion-light files. - Keep the heavy assertion tree out of the main process. Error serialization pulled in all of assert.js (Concordance, lodash, the snapshot manager) only for the `AssertionError` class used in an `instanceof` check that is always false in the main process. The class now lives in its own tiny module. - Replace the stats deep-clone with a purpose-built copy. Run status cloned its stats object with a full `v8.serialize`/`deserialize` round-trip on every state change; the object is just flat counters and a map of flat counters, so a direct copy is ~20x faster. - Dispatch worker state-change events without Emittery. These are high-frequency, consumed synchronously and never awaited, so they bypass Emittery's per-emit async machinery. The rare shared-worker event still uses Emittery.
`RegExp.prototype.test()` advances `lastIndex` for a regex with the `g` or `y` flag, and the assertions called it on the caller's own regex, so a value that matched once failed the next time.
`t.regex('foo', /foo/g)` passed, then threw `Value must match expression: 'foo' / Regular expression: /foo/g` for the next identical string. The same happened for `t.notRegex()` and for `{message: /boom/g}` on `t.throwsAsync()`, which routes through `assertExpectations()`.
Reset `lastIndex` before each test so the same input always gets the same verdict.
sindresorhus
force-pushed
the
improve-worker-startup-performance
branch
from
October 16, 2026 06:03
c6cda2a to
5e60c85
Compare
Member
Author
|
done |
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
2 participants
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.
Profiling the worker and main processes under load surfaced overhead that scales with the number of test files and events rather than the work the tests actually do. This cuts that overhead substantially:
The gains come from reducing per-worker module loading and per-event main-process work.
Changes:
Defer heavy worker dependencies until actually needed. Workers loaded the glob stack (via the provider manager), the line-number parser (acorn) and write-file-atomic eagerly, though plain-JavaScript files with no line-number filter never use them. They now load lazily.
Load Concordance lazily. Concordance and its lodash dependency (~22ms to evaluate) were loaded in every worker via the assertions, test and snapshot modules, and in the main process via error serialization, even though passing simple assertions, plain
t.logcalls, snapshot-free runs and worker-level errors never touch it. A small shared module loads it on first use. This roughly halves the worker module-load tree or assertion-light files.Keep the heavy assertion tree out of the main process. Error serialization pulled in all of assert.js (Concordance, lodash, the snapshot manager) only for the
AssertionErrorclass used in aninstanceofcheck that is always false in the main process. The class now lives in its own tiny module.Replace the stats deep-clone with a purpose-built copy. Run status cloned its stats object with a full
v8.serialize/deserializeround-trip on every state change; the object is just flat counters and a map of flat counters, so a direct copy is ~20x faster.Dispatch worker state-change events without Emittery. These are high-frequency, consumed synchronously and never awaited, so they bypass Emittery's per-emit async machinery. The rare shared-worker event still uses Emittery.