[Dylan16807]

> No, seriously, give an ash-derivative a try.

To solve the problem or because you saw "slow" and "bash" and wanted to bring up something cool but unrelated?

If I go from 10 seconds of forking and .04 seconds of shell to 10 seconds of forking and .01 seconds of shell, I don't actually care about how cool and fast the shell is. And I've never had the speed of bash itself be a problem.

[chasil]

No, because the Ada gsh also proved that the POSIX shell syntax could perform far better.

Bash is prominent in announcing that it is "too big and too slow." It has said this for years. Why are its supporters so firmly in denial?

[Dylan16807]

Your focus here, with a whole comment just quoting the line, makes it sound like you're motivated by smugness, not an actual attempt to help.

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.

[chasil]

I actually need a fast shell.

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.

[Dylan16807]

> diametrically opposed to the facts of this situation

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.

[chasil]

  $ rpm -q bash
  bash-5.1.8-9.el9.x86_64

  $ man bash | sed -n '/BUGS/,/^$/p'
  BUGS
       It's too big and too slow.