3 ms·

Wait, a subshell is a child process, right? I would imagine there would be performance implications of defining every bash function as a subshell, is why it's

Wait, a subshell is a child process, right? I would imagine there would be performance implications of defining every bash function as a subshell, is why it's not universally recommended to define functions this way? No?

deleted 5y ago
[deleted]
zegl 5y ago
I did a quick test, and function calls using the subshell type of function seems to be about twice as slow as normal function calls. #!/bin/bash fib1() { if (( $1 < 2 )) ; then echo $1 return 0 fi echo $(( $(fib1 $(($1-1))) + $(fib1 $(($1-2))) )) return 0 } fib2() ( if (( $1 < 2 )) ; then echo $1 return 0 fi echo $(( $(fib2 $(($1-1))) + $(fib2 $(($1-2))) )) return 0 ) time fib1 15 time fib2 15 Result: 610 real 0m1.585s user 0m0.590s sys 0m0.972s 610 real 0m3.168s user 0m1.068s sys 0m2.025s
- jrochkind1 5y ago
  It probably doesn't matter too much if you have only a handful of function invocations in your exec. But if you have a a couple orders of magnitude more... RAM is going to be an issue too maybe. Creating a new process for every single function invocation seems crazy to me, and but might actually be just fine for many "ordinary" use cases? (Although might not have been on computers of 20+ years ago, which might also be why it's not something advised, so much of bash tradition is decades old?)
  - kevincox 5y ago
    Of course the subshell is copy-on-write so the ram requirements shouldn't be huge. But assuming some stack you are using at least some stack in each process you are looking at 4k per call which adds up fairly quickly.
chubot 5y ago
Yes, and that's my reaction too. While I can see the rationale for always starting another process, in practice I haven't found the leakage to be a big problem. Actually Oil functions don't use dynamic scope, but this is done in-process, not with another process: https://www.oilshell.org/release/latest/doc/variables.html#procs-dont-use-dynamic-scope https://www.oilshell.org/release/latest/doc/variables.html#p... ---- Also nested functions don't really add much useful to shell. It's purely a matter of textual code organization and doesn't affect the semantics. I define all functions at the top level.
fragmede 5y ago
subshells don't propagate information out which makes them hard to work with in many cases. Ie ((foo=42)); echo $foo is not going to have 42.
dataflow 5y ago
Yeah, try subshells on MSYS2 and see how performance goes.
laumars 5y ago
If your hot path needs that level of micro-optimisation then you’re far better off rewriting it an language that compiles instead of interprets and forks. Even Ruby and Perl would run circles around Bash.
arendtio 5y ago
If you care about performance, you better don't write shell scripts. The typical task of a shell script is to start programs and connect them in a meaningful way. This is in itself a pretty expensive task performance wise. So arguing about the cost of sub-shells is somewhat besides the point.

deleted 5y ago

[deleted]

zegl 5y ago

I did a quick test, and function calls using the subshell type of function seems to be about twice as slow as normal function calls. #!/bin/bash fib1() { if (( $1 < 2 )) ; then echo $1 return 0 fi echo $(( $(fib1 $(($1-1))) + $(fib1 $(($1-2))) )) return 0 } fib2() ( if (( $1 < 2 )) ; then echo $1 return 0 fi echo $(( $(fib2 $(($1-1))) + $(fib2 $(($1-2))) )) return 0 ) time fib1 15 time fib2 15 Result: 610 real 0m1.585s user 0m0.590s sys 0m0.972s 610 real 0m3.168s user 0m1.068s sys 0m2.025s

jrochkind1 5y ago
It probably doesn't matter too much if you have only a handful of function invocations in your exec. But if you have a a couple orders of magnitude more... RAM is going to be an issue too maybe. Creating a new process for every single function invocation seems crazy to me, and but might actually be just fine for many "ordinary" use cases? (Although might not have been on computers of 20+ years ago, which might also be why it's not something advised, so much of bash tradition is decades old?)
- kevincox 5y ago
  Of course the subshell is copy-on-write so the ram requirements shouldn't be huge. But assuming some stack you are using at least some stack in each process you are looking at 4k per call which adds up fairly quickly.

chubot 5y ago

Yes, and that's my reaction too. While I can see the rationale for always starting another process, in practice I haven't found the leakage to be a big problem. Actually Oil functions don't use dynamic scope, but this is done in-process, not with another process: https://www.oilshell.org/release/latest/doc/variables.html#procs-dont-use-dynamic-scope https://www.oilshell.org/release/latest/doc/variables.html#p... ---- Also nested functions don't really add much useful to shell. It's purely a matter of textual code organization and doesn't affect the semantics. I define all functions at the top level.

fragmede 5y ago

subshells don't propagate information out which makes them hard to work with in many cases. Ie ((foo=42)); echo $foo is not going to have 42.

dataflow 5y ago

Yeah, try subshells on MSYS2 and see how performance goes.

laumars 5y ago

If your hot path needs that level of micro-optimisation then you’re far better off rewriting it an language that compiles instead of interprets and forks. Even Ruby and Perl would run circles around Bash.

arendtio 5y ago

If you care about performance, you better don't write shell scripts. The typical task of a shell script is to start programs and connect them in a meaningful way. This is in itself a pretty expensive task performance wise. So arguing about the cost of sub-shells is somewhat besides the point.