
Ask HN: When startup time for CLI tools starts bothering you? - m45t3r
I am developing a CLI tools for internal usage to substitute the old tooling that we have, and one of the things that I am trying to optimize is startup time.<p>Why? Because with the old tools, every time that one command took more than a second I would unconsciously avoid this command, even if it was useful (of course, there are exceptions, i.e.: commands that are rarely used).<p>However, I only have arbitrary values for benchmark based on startup times that irritates me. This is basically what I am using as a base to measure against:<p>- ~0.1s: good, feels instantaneous<p>- ~0.2s: ok, however the latency starts to be perceptible<p>- ~0.5s: slow but bearable<p>- ~1s: I actively avoid to use this command unless necessary<p>A very simple test that you can do in your shell:<p><pre><code>     foo() { sleep 0.1 &amp;&amp; echo &quot;Hello&quot; }
</code></pre>
And afterwards, call `foo`. You can of course play with `sleep` values to simulate other startup times.<p>Remember that I am looking at startup time, so it is the time until the commands gives some feedback. The command itself can takes more time than +10s to run, for example, however if it gives feedback in ~0.1s it still feels good.
======
PaulHoule
It depends on what the command does, also how much faith I have in the
reliability of it.

If there was to be a "computer user's bill of rights" in 2019 it would be that
you have the right to get some feedback that it has really started the task
that you think you did. If there is one thing I hate about Windows it is that
I type [Win] + "cmd", then nothing happens, then I try it again, nothing
happens, then after 20 seconds I have five console windows pop up.

I've had this pet peeve with every kind of GUI and Modern Web application, but
never felt this way about command line applications.

