Optimizations are cool and all, but being 4x faster at something that's already taking negligible time is not something that makes a big difference.
How long ago was that line written anyway? It feels like complaining about emacs using its "8 megabytes" of memory in the modern day.
The solution to this problem is to reduce the number of forks. Faster code on either side is aesthetically nice but unhelpful.
It's not "denial" to acknowledge that an already-fast program has a faster replacement and then get back to working on the bottlenecks.
So did Debian and Ubuntu, so they demoted bash.
Whatever smugness you are interpreting here is diametrically opposed to the facts of this situation, and repeat after me:
It’s too big and too slow.
What do you think 'this situation' is?
Repeat after me: The situation is that fork is using almost all the runtime.
The only solutions are fixing fork or forking less. Your suggestions are not related to the actual problem the user is having.
Optimizations are cool and all, but being 4x faster at something that's already taking negligible time is not something that makes a big difference.
How long ago was that line written anyway? It feels like complaining about emacs using its "8 megabytes" of memory in the modern day.
The solution to this problem is to reduce the number of forks. Faster code on either side is aesthetically nice but unhelpful.
It's not "denial" to acknowledge that an already-fast program has a faster replacement and then get back to working on the bottlenecks.