Startup time performance investigation

In order to figure out how to make it faster, I wanted to see how it looked like right now.

Node startup time

Doing nothing with node takes ~40ms. So no matter what we do, we’ll never be able to get below 40ms.

time node -e ''
real	0m0.043s

Prettier startup time

Pretty printing an empty file with prettier takes ~150ms. This includes loading all the JavaScript and parsing/generating IR/printing nothing… :p

time echo '' | ./prettier.js --stdin > /dev/null
real	0m0.153s

Printing a 2k lines file

It takes ~420ms to print a 2.5k lines file.

time ./prettier.js ../src/printer.js > /dev/null
real	0m0.425s

npm run time

npm run startup time is ~380ms. This means that you consistently pay the overhead just for the fancy alias.

"scripts": {
    "donothing": "true",

time npm run donothing > /dev/null
real	0m0.383s

yarn run time

yarn run startup time is ~240ms. This is better (even though it’s still super slow).

time yarn run donothing > /dev/null
real	0m0.246s

Conclusion

If we want a snappy experience inside of the editor, we’ll likely want to load the JavaScript code once and then use it multiple times. We absolutely don’t want to do npm run prettier on every save otherwise we’d have to pay for half a second (380ms + 150ms = 530ms) every single time!

[jlongster]

Luckily we don’t encourage using npm or yarn in production, people just use the prettier CLI.

Atom gets the benefit of already being in JS, so it loads the module once and will reuse it.

For other editors, we do re-execute the script every single time. For smaller files it’s acceptable, but if we want to fix this, we’d need to start a “server” or something that can persist across executions.

I’m curious how much the 420ms for a 2k lines file goes down after JIT. You’d have to write a custom script for that which runs it multiple times.

[vjeux]

This is not very actionable, I’m closing this issue.