I'd say they are both slow. Try Perl, Tcl, Lua or some other interpreted language that starts fast, and you'll likely see something like 200-300ms for the equivalent commands to above.

As in so many measurement/benchmarking situations, "compared to what?" is indeed The Big Question.

For example, you can also compare to a C program not doing much, overhead-wise:

    /usr/bin/time bash -c 'for i in {1..100}; do /bin/true; done'

which gives me like 70 ms for all 100 or 0.7ms per each startup, with also some adjustment to start-up the bash driver shell itself.

Even that 700 microseconds is a high number, from glibc & dynamic linking mostly. If you

    echo 'int main(int ac,char**av){return 0;}' > /tmp/true.c
    musl-gcc -static -O2 /tmp/true.c -o /tmp/true

and repeat, you see 380 microseconds per each.

In benchmarking scenarios requiring more elaboration than makes sense in an HN comment, I see times as low as 140 microsec per run on that same machine/OS. In fact, as you push things to low overhead extremes, you can easily see the impact of how much environment variable data is in play (`env -i` vs. not).

It is true that Python start-up time is not that bad compared to a "mean diameter of the Internet in milliseconds" which is probably the relevant time scale for CGIs, but it's probably not so small as to be truly negligible, esp. once imports are happening.

Also, Python3 remains quite a bit slower (1.7X slower on that same machine) to start-up than Python2 even after more than a decade of promises to claw back start-up performance.

Meanwhile, on the other side of the comparison, starting up a Julia REPL seems to take quite a bit longer than the Python 16 ms..Like 340ms or 20X longer.

So, the overarching point of this overlong post is just a follow-up/supporting of @tyingq's "compared to what?" with a little more detail.

    echo 'print 1' > test.perl; time for i in {1..100}; do perl test.perl > /dev/null; done

Gives me 0.25s

Clearly the winner!