So I was getting tired of waiting around for all my command-line tools to start up. And sure, you might say, a few hundred milliseconds isn't that much. But multiply that by dozens and dozens of calls from ci/cd and scripts, and now you're starting to talk about a real slowdown.
And then I thought, well, maybe I'll just write my own OS. But then I actually looked at the numbers, and most of that time isn't spent in the kernel. It's spent starting up the interpreter and loading the code for my tools.
And then it hit me. What if I just loaded each of my tools once, kept them in memory, and then forked a copy whenever I actually needed one? And maybe I'd even write the client in Rust so it would be blazing fast.
So how much of an improvement is there? Well, I've got a benchmark in the repo that runs eslint on a file. Natively it takes 328 ms, and with a warm daemon it takes 43 ms, so that's pretty sweet.
And of course there's a whole bunch of commands, 96 in all, and 69 of them just print out a version or a help page or something like that. The median speedup is actually 4.9x, but if I just look at the 27 commands that actually do something, then it's more like 4x. And all 96 gave the same output and exit code as running them normally.
One thing I really wanted to avoid was running a command twice. So if something goes wrong before it starts, speedrunner falls back to the normal tool. But once it's started, it won't run it again.
And of course the first call still runs natively if the daemon isn't already up and running, and there's some memory usage. But the idea isn't entirely new. Spring does this sort of thing for Rails, there's Nailgun for the JVM, and JumpTheGun and quicken do something similar for Python. But this is an attempt to generalize it across multiple languages. And Node is still a little bit experimental. It runs on Linux and macOS, but not Windows.
To try it, install speedrunner and run:
speedrunner demo
It measures the gains using whichever tools it recognizes on your machine. So if you don't have many of those installed, there won't be as much to measure. And I'd be happy to hear which tools it doesn't serve very well, or what fork pitfalls I've missed.
anthonygosme•54m ago
So I was getting tired of waiting around for all my command-line tools to start up. And sure, you might say, a few hundred milliseconds isn't that much. But multiply that by dozens and dozens of calls from ci/cd and scripts, and now you're starting to talk about a real slowdown.
And then I thought, well, maybe I'll just write my own OS. But then I actually looked at the numbers, and most of that time isn't spent in the kernel. It's spent starting up the interpreter and loading the code for my tools.
And then it hit me. What if I just loaded each of my tools once, kept them in memory, and then forked a copy whenever I actually needed one? And maybe I'd even write the client in Rust so it would be blazing fast.
So how much of an improvement is there? Well, I've got a benchmark in the repo that runs eslint on a file. Natively it takes 328 ms, and with a warm daemon it takes 43 ms, so that's pretty sweet.
And of course there's a whole bunch of commands, 96 in all, and 69 of them just print out a version or a help page or something like that. The median speedup is actually 4.9x, but if I just look at the 27 commands that actually do something, then it's more like 4x. And all 96 gave the same output and exit code as running them normally.
One thing I really wanted to avoid was running a command twice. So if something goes wrong before it starts, speedrunner falls back to the normal tool. But once it's started, it won't run it again.
And of course the first call still runs natively if the daemon isn't already up and running, and there's some memory usage. But the idea isn't entirely new. Spring does this sort of thing for Rails, there's Nailgun for the JVM, and JumpTheGun and quicken do something similar for Python. But this is an attempt to generalize it across multiple languages. And Node is still a little bit experimental. It runs on Linux and macOS, but not Windows.
To try it, install speedrunner and run:
It measures the gains using whichever tools it recognizes on your machine. So if you don't have many of those installed, there won't be as much to measure. And I'd be happy to hear which tools it doesn't serve very well, or what fork pitfalls I've missed.