5 ms·

Honest question, what use case have people run into with non scripts that a 300ms startup time is painful for? Mine have always been simple and run not very oft

by girvo 5y ago

Honest question, what use case have people run into with non scripts that a 300ms startup time is painful for? Mine have always been simple and run not very often, so it’s barely mattered to me, but I’m sure I’m missing some obvious uses that others have

staticelf 5y ago
Maybe for stuff that runs over and over again and needs every microsecond it can get. But if that's a requirement, nodejs seems like a pretty bad choice anyway.
zebracanevra 5y ago
In the past, tools were slow, so everyone was forced to use "watch" modes in their tools, so startup time didn't matter much. Nowadays, we have esbuild and a whole suite of other tools that run in <10ms, so a slow startup time is dreadful.
- girvo 5y ago
  Ah that’s fair. Most of the tooling I’m running is still honestly pretty slow (CRA being the main set, Jest being the other), and they both do the “watch” trick.
- folkrav 5y ago
  I've always used --watch just so my stuff would re-run without me having to manually do it...? That watch modes were to get around slow startup, and not a usability feature, is new information to me.
dmw_ng 5y ago
That's a question designed to confirm priors, depending on perspective it's not necessarily an honest one. It's better to think about changes like this in terms of what becomes possible with overheads removed ("what becomes more convenient to do as an npm script if startup is much faster?") or comparable examples from other areas ("what happened to the web when it no longer became necessary to wait 300ms+ for application logic to respond to a click?") etc.
- girvo 5y ago
  Sure, that’s what I was trying to get at but worded badly. What am I missing that this would help with, and that NPM scripts are the right choice for them? Git hooks as someone mentioned below are a good one. It absolutely was an honest question, and nitpicking on my intent to imply I think this project is silly seems a little unnecessary: I don’t, and really do want to know what it could help with, as none of my use cases need it right now. I’d like to keep any eye out for when they would though.
  - berkes 5y ago
    For me, speedup enables a lot of much simpler ways to do the stuff that I already do. Run tests and linter on-save. Have vim with LSP and other tooling, startup fast enough to close and re-open the entire editor, rather than background (<CTRL>-z) or alt-tab. Just do a <CTRL>-c<CTRL-p><enter> to reload any changes in a running dev server, rather than tooling that attempts to listen to io-events and reload the code magically. There are loads of small things that become a lot simpler when kill&start is just as fast as "internal reload".
Cthulhu_ 5y ago
It adds up. 300ms is pretty good, but that's just starting up a node process, then you get a long process of parsing and executing the script itself. Which initially is not too bad, but the bigger the codebase gets and the more often you run it, it adds up. 300ms per invocation is something that a lot of CI providers would love to save. Relevant XKCD: https://xkcd.com/1205/ https://xkcd.com/1205/
- bin_bash 5y ago
  That doesn't apply here: all these scripts do is shell out to some other binary. Any performance cost of using node or other binary is going to be exactly the same. It's 200-300ms regardless of what the underlying script does.
bin_bash 5y ago
git hooks
- ______-_-______ 5y ago
  Especially when you have 6 git hooks, and they're all run one by one in "pre-commit", which is written in Python, another whole slow interpreted ecosystem. I do not miss my last job.
- girvo 5y ago
  That’s a good one I hadn’t considered. Definitely going to keep this tool in mind if we ever need to run some hooks from npm scripts.
- scns 5y ago
  This one might help: https://github.com/evilmartians/lefthook https://github.com/evilmartians/lefthook
krageon 5y ago
Anything that takes 300ms to start up is not suitable for anything but server applications (and even then...) or daemons. Nothing living in userspace should be that slow, IMO.

by girvo 5y ago

staticelf 5y ago

Maybe for stuff that runs over and over again and needs every microsecond it can get. But if that's a requirement, nodejs seems like a pretty bad choice anyway.

zebracanevra 5y ago

In the past, tools were slow, so everyone was forced to use "watch" modes in their tools, so startup time didn't matter much. Nowadays, we have esbuild and a whole suite of other tools that run in <10ms, so a slow startup time is dreadful.

girvo 5y ago
Ah that’s fair. Most of the tooling I’m running is still honestly pretty slow (CRA being the main set, Jest being the other), and they both do the “watch” trick.
folkrav 5y ago
I've always used --watch just so my stuff would re-run without me having to manually do it...? That watch modes were to get around slow startup, and not a usability feature, is new information to me.

dmw_ng 5y ago

That's a question designed to confirm priors, depending on perspective it's not necessarily an honest one. It's better to think about changes like this in terms of what becomes possible with overheads removed ("what becomes more convenient to do as an npm script if startup is much faster?") or comparable examples from other areas ("what happened to the web when it no longer became necessary to wait 300ms+ for application logic to respond to a click?") etc.

girvo 5y ago
Sure, that’s what I was trying to get at but worded badly. What am I missing that this would help with, and that NPM scripts are the right choice for them? Git hooks as someone mentioned below are a good one. It absolutely was an honest question, and nitpicking on my intent to imply I think this project is silly seems a little unnecessary: I don’t, and really do want to know what it could help with, as none of my use cases need it right now. I’d like to keep any eye out for when they would though.
- berkes 5y ago
  For me, speedup enables a lot of much simpler ways to do the stuff that I already do. Run tests and linter on-save. Have vim with LSP and other tooling, startup fast enough to close and re-open the entire editor, rather than background (<CTRL>-z) or alt-tab. Just do a <CTRL>-c<CTRL-p><enter> to reload any changes in a running dev server, rather than tooling that attempts to listen to io-events and reload the code magically. There are loads of small things that become a lot simpler when kill&start is just as fast as "internal reload".

Cthulhu_ 5y ago

It adds up. 300ms is pretty good, but that's just starting up a node process, then you get a long process of parsing and executing the script itself. Which initially is not too bad, but the bigger the codebase gets and the more often you run it, it adds up. 300ms per invocation is something that a lot of CI providers would love to save. Relevant XKCD: https://xkcd.com/1205/ https://xkcd.com/1205/

bin_bash 5y ago
That doesn't apply here: all these scripts do is shell out to some other binary. Any performance cost of using node or other binary is going to be exactly the same. It's 200-300ms regardless of what the underlying script does.

bin_bash 5y ago

git hooks

______-_-______ 5y ago
Especially when you have 6 git hooks, and they're all run one by one in "pre-commit", which is written in Python, another whole slow interpreted ecosystem. I do not miss my last job.
girvo 5y ago
That’s a good one I hadn’t considered. Definitely going to keep this tool in mind if we ever need to run some hooks from npm scripts.
scns 5y ago
This one might help: https://github.com/evilmartians/lefthook https://github.com/evilmartians/lefthook

krageon 5y ago

Anything that takes 300ms to start up is not suitable for anything but server applications (and even then...) or daemons. Nothing living in userspace should be that slow, IMO.