Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-IrsGKQ/bash-4.4=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall -no-pie
-Wno-parentheses -Wno-format-security
uname output: Linux sint 4.13.0-36-generic #40-Ubuntu SMP Fri Feb 16 20:07:48
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4
Patch Level: 12
Release Status: release
Description:
When a function is ran in a subshell environment (via backticks),
the program runs faster when that function also writes to stderr.
This effect does not occur when stderr is redirected to /dev/null
Expected that, the version writing to stderr would be slower.
I am not sure where the problem lies.
It could be bash, terminal, X, kernel or hardware.
Tested this on XWayland, gnome-terminal (with and without tmux),
and xterm.
Hope you can help.
Regards, Mike
Repeat-By:
An example program that exhibits the described behaviour:
####### cut here #######
#!/bin/bash
sub () {
if [ "$SPEED" = fast ]; then
echo -n fast >&2
fi
echo sub
}
prog () {
declare x line
while read line; do
x=`sub`
done < <(cat /etc/services /etc/services)
}
main () {
local -g SPEED="$1"
local -i i=${RUNS:-10}
local start
echo $SPEED
while [ $((i--)) -gt 0 ]; do
start=$(date +%s%N)
prog
echo $(( ($(date +%s%N) - $start)/1000000 ))
done
}
main "$@"
####### cut here #######
When saved as 'bug.bash' and ran as :
./bug.bash slow < <( cat /etc/services /etc/services )
slow
1644
1652
1663
1663
1661
1658
1656
1653
1646
1641
On the other hand, when ran as:
./bug.bash fast < <( cat /etc/services /etc/services )
fast
443
424
436
422
439
421
433
428
425
435
(numbers are thousands of seconds in a single run)
The second, fast-version, does more, but takes less time.
Note that when the fast version is ran with 2>/dev/null,
it also performs slowly.
I have looked at the strace's of both variants, but saw
nothing realy different.
