1. 34
  1. 15

    Between OMZ making the shell take 3s to start on an SSD, and asking whether it can check for updates, I’m not sure it lasted more than 3 days on my machine. :)

    More to the point: rather than starting with OMZ and asking, “what can I get rid of?” I’d encourage the opposite view of asking “what do I need?” and adding that to a simple zsh setup. Take ownership of your workspace and add only what you fully understand. I really like a simple prompt with CWD, current git branch (if any), and dirty status. My shell needs are also very simple, and I’m still learning a lot about what plain zsh can do. Add aliases as you need them instead of using giant community-driven plugins.

    I really feel like our workspaces should be slightly idiosyncratic, if only to surface better workflows over time. Frameworks cut this impulse off at the knees.

    The benefit of this approach:

       ❯ time zsh -i -c exit
           0.05 real         0.04 user         0.01 sys
    1. 4

      I really like a simple prompt with CWD, current git branch (if any), and dirty status.

      In that case perhaps you’ll like my prompt. It relies on and sources these two simple functions.

      Time varies from 0m0.006s to 0m0.009s.

      1. 1

        Yeah, I’ve always felt OMZ (and similar things for emacs, etc.) kind of miss the point.

        Dot files and tool configuration allow everybody to optimize their workflow so that it works best for their needs. Maybe using a collection of other people’s customizations really works best for some people, but it seems sub-optimal in general.

      2. 7

        If you like oh-my-zsh, I recommend checking out Zim as well. I haven’t used oh-my-zsh in a few years so I can’t speak about that, but my Zim-based setup’s startup time with 13 modules and a couple other plugins averages around 0.04 seconds, i.e. as fast as author’s bash startup time. And I haven’t done any profiling/optimizations beyond whatever Zim comes with.

        1. 1

          I’m a big fan of Zim too. I’ve tried oh-my-zsh, Pure, and a few others too.

        2. 2

          I spent some time a few years ago speeding up my own shell (I think I was up to around 5 seconds startup time), and replacing Oh-My-Zsh with hand-built files was one of the biggest wins.

          Out of interest I just timed it, and it’s still under half a second so I’m happy. (Although Zim looks interesting, thanks for pointing that out @aminb!)

          $ echo -n "$SHELL "; for i in {1..10}; do /usr/bin/time $SHELL -ic exit; done |& awk '{ i += $1 } END { print i/NR }'
          /usr/local/opt/zsh/bin/zsh 0.34

          How fast does your shell start?

          1. 3

            Nice :) And no problems.

            How fast does your shell start?

            Here’s mine:

            ➜ echo -n "$SHELL "; for i in {1..10}; do /usr/bin/time $SHELL -ic exit; done |& awk '{ i += $1 } END { print i/NR }'
            /bin/zsh 0.0206667
            1. 1

              $HOME/.brew/bin/fish : 0.0241765

            2. 1

              I really don’t understand why we need to optimize a shell.

              ; echo -n $SHELL' ';{for(i in `{seq 1 10}){/usr/bin/time $SHELL -ic exit}}>[2=1]|awk '{i+=$1}END{print i/NR}'
              /p9p/bin/rc 0
              1. 3

                Mostly to avoid flow state interruptions. I want tools that stay out of the way. Prompting for updates I just want to do work is dumb.

            3. 2

              We’ve done some work on prezto to improve performance as well. We ended up going with one of the tradeoffs mentioned with completion - only regenerate once a day.

              I’ve also got my own set of utils that I’m slowly porting from prezto (https://github.com/belak/zsh-utils). I’ve found that both OMZ and prezto tend to do a ton of things I don’t want (which obviously slows it down) - there are plenty of instances where I just want a more sane version of the default config.

              If you have suggestions or performance improvement ideas for either prezto or zsh-utils, definitely file an issue, submit a PR, or let me know. I’d be happy to take a look.

              1. 1

                The high count for times that compdef is run indicates that this run is without a cache for compinit. The lack of calls to compdump also indicates that it isn’t creating a dump file. This cache, speeds compinit startup massively. I’m not quite sure how the blog post author has contrived to not have a dump file.

                1. 4

                  “contrived” is a rather strong word to use here and suggests intent (perhaps to deceive). I’m not sure if it was your intent or not.

                  1. 3

                    This actually is with a dump file. A .zcompdump-MACHINENAME file is created in ~ (see here).

                    The issue is that this is recreated each time the shell starts up. There are multiple places in OMZ that call compinit. In the additional reading at the bottom there is a link that modifies zsh to only recreate it once a day, but I still feel like that’s not ideal.

                    1. 2

                      Can you redefine compinit to a no-op during OMZ loading, and then do it yourself at the end?

                      IMO zshrc should explicitly call compinit so it happens exactly once in a central location.

                    2. 2

                      Maybe he didn’t know?

                    3. 1

                      Oh My Zsh has some killer features but speed is definitely one of the reasons I gave up and switched back to bash. Another reason is standardization - so many shops I work at have fairly evolved bash configs you kinda HAVE to use if you want to be able to do the thing, so it’s not worth fighting upstream over.

                      1. 1

                        I’m in a similar boat, but it was with the grml collection of zsh extensions/scripts. I tried it and loved it a few years back, sticking with it for at least a few months.

                        One day I was forced to use bash again. It felt oddly fast – my prompt would reappear after a command exited much earlier than usual. I did some comparison with my loaded zsh setup and discovered I could really “feel” the difference. What finally clinched it was waiting for zsh to load on a heavily burdened system with runaway disk IO. I felt like I wasn’t in control anymore.

                        I didn’t want to let go of the better tab-completion features (especially using cd when there’s only one folder and many files) and to this day I still get stunlocked occasionally by the lack of them. It’s amazing how quickly some expectations and habits of mine developed, and how long they’ve lasted. But I don’t think I can go back to slowsville.