jstevans / waste-not

A caching system to help tools run incrementally w.r.t. file contents and the dependency graph
https://www.npmjs.com/package/waste-not
MIT License
1 stars 0 forks source link

Preliminary performance analysis #7

Open jstevans opened 4 years ago

jstevans commented 4 years ago

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 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

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 TestScheduler

  no waste-not waste-not (cold) waste-not (warm)
jest ~3sec ~34sec ~32sec
jest --clearCache && jest ~8sec ~41sec ~32.5sec

Test execution time

start: just after waste-not has finished initializing end: when the final results are returned by the TestScheduler

  no waste-not waste-not (cold) waste-not (warm)
jest ~2.5sec ~2.5sec ~150ms
jest --clearCache && jest ~7.5sec ~7.5sec ~150ms

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 in node_modules; I have a WIP branch to add a special-case for packages in node_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 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.