3 ms·

If a tool is written in an interpreted language or has to load a large VM on each invocation than a large percentage of the total runtime of the CLI tool will b

by shawn 8y ago

If a tool is written in an interpreted language or has to load a large VM on each invocation than a large percentage of the total runtime of the CLI tool will be spent on language-specific tasks. This is a myth, FWIW. LuaJIT, python, and node all load within 150ms. And it's usually closer to 70ms: https://gist.github.com/shawwn/544b643bba018fb6bd302a5c46222ca6 https://gist.github.com/shawwn/544b643bba018fb6bd302a5c46222...

pests 8y ago
A single print statement? That is extremely artificial. I'd like to to see numbers wheb you're loading dependencies and on a real workload. That's barely even making use of those languages runtimes as well.
- shawn 8y ago
  Why load dependencies when the task is text transformation? It’s not artificial. Importing the regex libs won’t affect the results by more than a rounding error.
- londt8 8y ago
  The comment was about loading a large VM at each invocation, so only minimal example is sufficient.
  - pests 8y ago
    Sure, technically. We were talking about start up time when using a CLI tool. Loading a VM is only part of that.
lifthrasiir 8y ago
While it us technically possible to optimize dependency relations to minimize the startup cost for minimal tasks, it is very hard to do in reality. In the "oxidation" plan of the Mercurial SCM [1] this problem was directly addressed and one of the first suggested targets to switch to Rust was an alternative CLI frontend. [1] https://www.mercurial-scm.org/wiki/OxidationPlan https://www.mercurial-scm.org/wiki/OxidationPlan
leshow 8y ago
In 150ms the other tool would be finished before any of those had even begun. Plus, this is for a print statement, you'd have to factor in dependencies as well to get a real idea of how long it took.
- hegz 8y ago
  That 150ms is especially important if the tool is running in a loop in a bash command.
arcticbull 8y ago
That is a long time, though. An eternity in terms of compute.
dbaupp 8y ago
With a warm cache, ripgrep takes 80-100ms to search 500MB of files across all the projects that I have checked out (for a regex like /val\w+;/ which matches 500 lines). Python starts (also from a warm cache) in 30ms on my machine. 30-40% seems like a large percentage by most measures.

by shawn 8y ago

pests 8y ago

A single print statement? That is extremely artificial. I'd like to to see numbers wheb you're loading dependencies and on a real workload. That's barely even making use of those languages runtimes as well.

shawn 8y ago
Why load dependencies when the task is text transformation? It’s not artificial. Importing the regex libs won’t affect the results by more than a rounding error.
londt8 8y ago
The comment was about loading a large VM at each invocation, so only minimal example is sufficient.
- pests 8y ago
  Sure, technically. We were talking about start up time when using a CLI tool. Loading a VM is only part of that.

lifthrasiir 8y ago

While it us technically possible to optimize dependency relations to minimize the startup cost for minimal tasks, it is very hard to do in reality. In the "oxidation" plan of the Mercurial SCM [1] this problem was directly addressed and one of the first suggested targets to switch to Rust was an alternative CLI frontend. [1] https://www.mercurial-scm.org/wiki/OxidationPlan https://www.mercurial-scm.org/wiki/OxidationPlan

leshow 8y ago

In 150ms the other tool would be finished before any of those had even begun. Plus, this is for a print statement, you'd have to factor in dependencies as well to get a real idea of how long it took.

hegz 8y ago
That 150ms is especially important if the tool is running in a loop in a bash command.

arcticbull 8y ago

That is a long time, though. An eternity in terms of compute.

dbaupp 8y ago

With a warm cache, ripgrep takes 80-100ms to search 500MB of files across all the projects that I have checked out (for a regex like /val\w+;/ which matches 500 lines). Python starts (also from a warm cache) in 30ms on my machine. 30-40% seems like a large percentage by most measures.