gettext boulder build times as a function of dash or bash as sh

ermo

@sunnyflunk asked me to do a test with 3 runs each of using boulder to build gettext, using first dash, then bash as /usr/bin/sh.

The test was run on an old AMD FX-8350 w/16 GiB RAM and a SATA-600 SSD via a ssh connection on the same OS configuration. This old platform was chosen to better highlight any difference in build times in percentage terms.

The summary is that, on this particular system, bash-as-sh results in ~ +20% longer build times with the current versions of dash and bash AFAICT.

Here are the results:

dash-as-/usr/bin/sh:
#1
The work directory %(workdir) is /mason/build/build/x86_64/gettext-0.21
[14:41:09] INFO      [Build] Finished: 3 minutes, 23 secs, 556 ms, 677 μs, and 3 hnsecs
[14:41:10] INFO      [Analyse] Finished: 218 ms and 972 μs
#2
The work directory %(workdir) is /mason/build/build/x86_64/gettext-0.21
[14:55:10] INFO      [Build] Finished: 3 minutes, 24 secs, 18 ms, 202 μs, and 9 hnsecs
[14:55:10] INFO      [Analyse] Finished: 233 ms, 542 μs, and 1 hnsec
#3
The work directory %(workdir) is /mason/build/build/x86_64/gettext-0.21
[15:02:32] INFO      [Build] Finished: 3 minutes, 25 secs, 368 ms, 189 μs, and 9 hnsecs
[15:02:32] INFO      [Analyse] Finished: 226 ms, 906 μs, and 6 hnsecs

bash as /usr/bin/sh:
#1
The work directory %(workdir) is /mason/build/build/x86_64/gettext-0.21
[15:15:56] INFO      [Build] Finished: 4 minutes, 5 secs, 566 ms, 440 μs, and 3 hnsecs
[15:15:56] INFO      [Analyse] Finished: 219 ms, 820 μs, and 8 hnsecs
#2
The work directory %(workdir) is /mason/build/build/x86_64/gettext-0.21
[15:20:45] INFO      [Build] Finished: 4 minutes, 4 secs, 148 ms, 860 μs, and 9 hnsecs
[15:20:46] INFO      [Analyse] Finished: 235 ms, 51 μs, and 1 hnsec
#3
The work directory %(workdir) is /mason/build/build/x86_64/gettext-0.21
[15:26:23] INFO      [Build] Finished: 4 minutes, 5 secs, 281 ms, 807 μs, and 8 hnsecs
[15:26:23] INFO      [Analyse] Finished: 236 ms, 784 μs, and 7 hnsecs

sunnyflunk

I thought the gap would be smaller with RELR support, but looks bigger. The percentage will likely decrease on a faster machine from previous observations on start up time of applications.

dash:

Just in general snappy.
Lacks some of the strange text substitution of bash, which can improve readability (i.e. more explicit) but people will try to use anyway.
Lack of some features means having to call external programs like grep/awk/ls to do what can be achieved with bash internals.
Can use the same parsing for errors of running code (note this is not shellcheck) (both the configure calls and stone.yml code.

bash:

We can probably make it a lot faster to startup and drop all the profile scripts etc particularly for use in boulder where it is execute only.
Only use it within boulder i.e. dash as sh but call /usr/bin/bash for the stages. Gives bash syntax in stone.yml and removes virtually all overhead.

ermo

sunnyflunk bash:
We can probably make it a lot faster to startup and drop all the profile scripts etc particularly for use in boulder where it is execute only.
Only use it within boulder i.e. dash as sh but call /usr/bin/bash for the stages. Gives bash syntax in stone.yml and removes virtually all overhead.

Is it silly to ask if we could have a static bash configured for use in boulder exclusively? I.e. minimal and heavily optimised/tweaked?

sunnyflunk

ermo Is it silly to ask if we could have a static bash configured for use in boulder exclusively? I.e. minimal and heavily optimised/tweaked?

If we just use bash for running the stages in boulder, then there's not much benefit (though we will obviously optimise bash anyway to make it faster). If we want to make bash the sh symlink then that's another kettle of fish to minimise the overhead.