4 ms·

Indeed, but: - when declaring routing in code, it's harder to shoot yourself in the foot. So many php sites expose what they should not, and .httaccess is rare

Indeed, but: - when declaring routing in code, it's harder to shoot yourself in the foot. So many php sites expose what they should not, and .httaccess is rarely crafted correctly - renaming files don't change your website - coding locally doesn't require apache if your tooling don't need it for routing. No need for stuff like EasyPhp - python dev servers automatically reload for you on changes anyway - declaring routes and parsing them at one place to get url id and slug is less duplication - declaring url yourself mean you can use the language typing system for their checking too (see fastapi) - I rarely need an entire file for one route endpoint, making 10 files for 10 enpoints that could fit in one is overkill - wsgi servers like gunicorn will hapilly reload the workers when it receives SIGHUP in prod. No need to restart the master process manually. - restarting a process every time mean you can't benefit much from nice python features like lru_cache, process/thread pools, connection pools, etc - python is slow to start, cgi takes a toll - it's easier to control the number of max workers that run an any given time Honestly, even when coding in PHP I will use phpfpm (which is one long running process like python) and frameworks like laravel (in which you declare your routing). I understand the desire for simplicity, and the one-file/one-route declaration is easy to get into. But if I want simple, I do a static website with a bit of client side JS, not need for a backend. When I do need a backend, I much prefer long running workers and explicit route declaration.

TekMol 4y ago
None of the points you mention are an argument against CGI for me. But it is mostly a matter of taste. There is one point I would like to address though: "python is slow to start" Python is slow. Dead slow. But not to start: echo 'print(1)' > test.py; time for i in {1..100}; do python3 test.py > /dev/null; done Gives me 1.6s echo '<?php echo(1);' > test.php; time for i in {1..100}; do php test.php > /dev/null; done Gives me 1.9s
- tyingq 4y ago
  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.
  - TekMol 4y ago
    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!
  - cb321 4y ago
    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.

TekMol 4y ago

None of the points you mention are an argument against CGI for me. But it is mostly a matter of taste. There is one point I would like to address though: "python is slow to start" Python is slow. Dead slow. But not to start: echo 'print(1)' > test.py; time for i in {1..100}; do python3 test.py > /dev/null; done Gives me 1.6s echo '<?php echo(1);' > test.php; time for i in {1..100}; do php test.php > /dev/null; done Gives me 1.9s

tyingq 4y ago
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.
- TekMol 4y ago
  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!
- cb321 4y ago
  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.