I wrote a little spike (jstevans/jest@f8982c8a9a7be109466da9bbda96bb504e517f1e) of how I imagine Jest using waste-not, and then got some early performance numbers by running the spike on the waste-not test suite.
Setup
# setup jest
git clone https://github.com/jstevans/jest.git
cd jest && yarn && cd packages/jest-cli && yarn link
cd ..
# setup waste-not and run `npm test`
git clone https://github.com/jstevans/waste-not.git
cd waste-not && yarn && yarn link jest-cli && npm test
For any given package, parsing dependencies from a package.json ought to be significantly faster than parsing dependencies out of all the modules in that package. Simply considering that this reduces the depth of the file-tree from the parser's perspective, let's consider this a 10x speedup within node_modules -- (~31sec * 0.1) + 1 sec) = ~4sec
Use waste-not on itself
waste-not itself currently isn't incrementalized (see #3), so it'll do the parsing work every time. I see ~99% of waste-not execution time is spent parsing files, so I expect incrementalization to be a significant speed-up.
Transcribed from a 2019-05-31 conversation
I wrote a little spike (jstevans/jest@f8982c8a9a7be109466da9bbda96bb504e517f1e) of how I imagine Jest using
waste-not
, and then got some early performance numbers by running the spike on thewaste-not
test suite.Setup
Results
Each cell contains the average of 3 executions.
Total jest time
start: when the tests have just been scheduled, i.e. test file paths have been computed, but not
fs.readFile()
'd end: when the final results are returned by the TestSchedulerjest
jest --clearCache && jest
Test execution time
start: just after
waste-not
has finished initializing end: when the final results are returned by the TestSchedulerjest
jest --clearCache && jest
Analysis
In this case, I see about ~32sec of overhead from
waste-not
. I have a couple of ideas to reduce that:Special-case
node_modules
According to a simple benchmark I took (see #1), ~96% (~31 seconds) of execution time in
waste-not
is spent parsing files innode_modules
; I have a WIP branch to add a special-case for packages innode_modules
.For any given package, parsing dependencies from a
package.json
ought to be significantly faster than parsing dependencies out of all the modules in that package. Simply considering that this reduces the depth of the file-tree from the parser's perspective, let's consider this a 10x speedup withinnode_modules
--(~31sec * 0.1) + 1 sec) = ~4sec
Use
waste-not
on itselfwaste-not
itself currently isn't incrementalized (see #3), so it'll do the parsing work every time. I see ~99% ofwaste-not
execution time is spent parsing files, so I expect incrementalization to be a significant speed-up.