[HN Gopher] My Faster Bash Startup (2020)
       ___________________________________________________________________
        
       My Faster Bash Startup (2020)
        
       Author : chmaynard
       Score  : 27 points
       Date   : 2021-10-30 05:58 UTC (17 hours ago)
        
 (HTM) web link (danpker.com)
 (TXT) w3m dump (danpker.com)
        
       | watermelon0 wrote:
       | It's amazing how slow shell prompts can be when you enable just a
       | few addons. It can easily take a few seconds to show a prompt.
       | 
       | I've had good results with
       | https://github.com/justjanne/powerline-go in the past.
        
       | krobelus wrote:
       | 200ms just for loading completions? :( fish avoids this with
       | lazy-loading
        
         | JoshTriplett wrote:
         | bash-completion does this too, these days. It doesn't load the
         | completions for a command until the first time you invoke
         | completion on that command.
        
       | codr7 wrote:
       | Me thinks I'm spending too much time on HN lately.
       | 
       | On the other hand, thank God it wasn't that kind of startup.
        
       | [deleted]
        
       | onedognight wrote:
       | TL;DR This post should be titled "`brew --prefix <formula>` is
       | slow, but I won't try and fix it; instead I'll hard-code some
       | paths".
        
         | mrHedgehog wrote:
         | I've found that `brew` itself is quite slow. I think the
         | problemis just with how brew does it's package management. I'm
         | not going to complain about it, because it's (IMO) better than
         | MacPorts.
        
           | naniwaduni wrote:
           | `brew help` alone takes a truly prodigious amount of time for
           | what it is.
        
       | encryptluks2 wrote:
       | Should be retitled My Faster Bash Startup. This had nothing to do
       | with Bash itself and everything to do with the user.
       | 
       | The big one is that Homebrew is abnormally slow in general and
       | they had multiple commands running homebrew in subshells.
        
         | grepfru_it wrote:
         | If you run ubuntu, disable all the call-home functions in
         | /etc/update-motd.d to speed up your bash login session
        
           | ta988 wrote:
           | I was wondering why Ububtu logins were always that slow. This
           | is ridiculous.
        
         | adrian_b wrote:
         | I have never tried to measure the startup time for interactive
         | bash, because my .bashrc only has a large number of environment
         | variables and of command aliases, so I do not see any visible
         | delay at startup.
         | 
         | However I have tried to benchmark bash against zsh, to see if
         | one of them is faster.
         | 
         | The benchmark was inconclusive, because I have tried 2 scripts,
         | but the execution times were essentially the same for both bash
         | and zsh.
         | 
         | The 2 scripts invoked a small shell script on each of about ten
         | thousand files and various file attributes were tested and
         | compared in some shell conditional expressions.
         | 
         | Because the times were the same for bash and zsh, it is likely
         | that the file operations dominated the execution time and not
         | the shell startup time or the script interpretation, as I
         | expected.
         | 
         | The shorter benchmark corresponded to an execution time of
         | about 10 millisecond per shell script, so this is an upper
         | limit for the bash startup time in non-interactive mode on my
         | computer.
         | 
         | It is likely that the startup time was several times less.
         | 
         | In conclusion, the startup of bash in non-interactive mode,
         | when it does not source .bashrc or other scripts, is no more
         | than a few millisecond.
         | 
         | It is clear that someone who wants bash to start fast should be
         | able to reach a startup time much, much less than a second.
        
         | dang wrote:
         | Ok, we've consed My onto the title above. Thanks!
        
       | CodeIsTheEnd wrote:
       | And if you want an increasingly _slower_ bash startup, you can
       | add the following to your coworker 's .bashrc/.bash_profile if
       | they keep forgetting to lock their screen when they go to grab a
       | snack:                   echo 'sleep 0.01' >> ~/.bashrc # or
       | ~/.bash_profile
        
       | chasil wrote:
       | Debian displaced bash as root's default, and now uses the
       | Almquist shell for performance reasons.
       | 
       | I would be curious if mksh is also faster. ksh93 also claims
       | great performance increases, but it is no longer (well)
       | maintained.
       | 
       | "Therefore, many interactive features are not present in Dash,
       | making it faster and more memory efficient than Bash."
       | 
       | https://wiki.debian.org/Shell
        
         | teddyh wrote:
         | > _Debian displaced bash as root 's default_
         | 
         | Um, no? Debian changed what _/ bin/sh_ is, which is what many
         | shell scripts use, especially those startup scripts used by
         | sysvinit. The shell of the root user remains, AFAIK, /bin/bash.
        
           | bbarnett wrote:
           | Indeed. Bash was used for sh emulation before, the reason
           | given for the change to dash was that sh emulation was more
           | correct with it.
           | 
           | (I think it allowed bashisms even when called as sh)
        
         | lhoursquentin wrote:
         | > I would be curious if mksh is also faster. ksh93 also claims
         | great performance increases, but it is no longer (well)
         | maintained.
         | 
         | mksh `printf` is not builtin, so if the script makes heavy use
         | of it then it tends to be slower than bash.
         | 
         | ksh is very interesting because it has the ability to avoid
         | spawning new processes on most command susbstitutions, making
         | it usually much faster than all other POSIX shells.
         | 
         | But again this depends heavily on what the script being
         | executed is doing, here's a highlight of what I described:
         | $ time mksh -c 'for i in $(seq 1000); do printf $(printf
         | $(printf $(printf hello))); done' > /dev/null              real
         | 0m2.121s       user    0m1.321s       sys     0m0.875s
         | $ time ksh -c 'for i in $(seq 1000); do printf $(printf
         | $(printf $(printf hello))); done' > /dev/null              real
         | 0m0.013s       user    0m0.008s       sys     0m0.005s
         | $ time dash -c 'for i in $(seq 1000); do printf $(printf
         | $(printf $(printf hello))); done' > /dev/null              real
         | 0m0.311s       user    0m0.279s       sys     0m0.073s
         | $ time bash -c 'for i in $(seq 1000); do printf $(printf
         | $(printf $(printf hello))); done' > /dev/null              real
         | 0m0.664s       user    0m0.538s       sys     0m0.186s
        
       ___________________________________________________________________
       (page generated 2021-10-30 23:01 UTC)