A free tool keeps command-line apps loaded so each call skips starting them again
The maker’s benchmark log includes a useful complication: an earlier accelerated pytest run failed tests because it reused the wrong application module.
A command-line tool can spend more time getting ready to work than doing the work. Multiply that by dozens of little calls in a check script and the computer gets a very busy morning with surprisingly little to show for it.
Speedrunner loads Python, Ruby, PHP and Node tools into daemons, then forks them for later invocations. Interpreter startup and reusable loading happen once. A formatter touching one file can benefit much more than a command whose real task already takes minutes.
The project’s README presents a mixed-language check script that went from 24.0 seconds to 5.3 on a two-vCPU VPS with the daemons warm. That is the maker’s workload and measurement. A script with different tools or longer tasks can spend far less of its time starting interpreters, leaving less time for this mechanism to save.
The more revealing result sits in the cold-and-warm follow-up. In its initial v0.4.2 runs, “pytest failed 11 tests.” The daemon had learned the first service’s application module and loaded it for later calls that needed something else.
Reusing loaded code sounds efficient right up until the code belongs to the previous customer. The benchmark’s correction matters because a stopwatch cannot distinguish a faster check from a check that examined the wrong application.
The follow-up reports medians of five runs on Debian 12. With the learning fix, the native script took 22.4 seconds, the cold-daemon run 7.0, and the warm run 4.8. The author says remaining output differences matched differences between native runs, including timestamps and other variable output. Those are separate measurements from the public 24.0-to-5.3 demo.
The known limits explain why the correction isn’t a universal proof. “What a tool makes as it loads is every call’s,” the guide warns. File state read during loading can remain the daemon’s copy; a random generator initialized then can repeat values across calls. The guide also lists terminal and process behaviors that can differ, including a child program failing when it expects its own controlling terminal.
A first ordinary invocation runs natively while its daemon starts, adding some overhead. Shell integration or the exec route can begin warming daemons earlier. The cold benchmark retained learned caches, too, so cold there means stopped daemons on a machine that had used the tools before. Those numbers therefore describe a user who has run the tools before, rather than the first invocation on an untouched installation.
Keeping more interpreters ready also means keeping processes and their memory around. The useful next comparison is the actual daily script, its idle daemon footprint, and the outputs it must preserve. The project supplies a measurable idea and an unusually candid failure record; how your own tool behaves after loading remains the part to establish.
The stopwatch doesn’t read test failures.