> FWIW, I zcompile my own rc files

What is the optimal way to compile a huge set of them? I've read Section 17 on zcompile, and it mentions "digest" files -- multiple files, containing named functions, where the .zwc is added to $fpath instead of the directory containing it.

It's trivial to set up an inotify watcher (Linux) or similar for other OSes ("brew install fswatch" seems to do fine on macOS) and recompile an entire tree on-modify. What I'm not aware of is any way to map dependencies between various scripts (e.g. "source A" → "source B" → "source C") such that when B changes, all of A/B/C get recompiled. In fact, due to the "source" keyword and Zsh internals, I'm not actually sure if it's even necessary or beneficial.

Zach Riggle

On Tue, Nov 30, 2021 at 3:12 AM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:

On Tue, Nov 30, 2021 at 9:27 AM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> It would be very useful to have an option to benchmark normal
> interactive shells instead of login shells

Sounds useful indeed. I added `--login no` (the default is yes).

> Also, you recommend against zcompiling .zshrc in your document, but
> first_command_lag_ms=56.709
> first_prompt_lag_ms=42.367
> exit_time_ms=40.885
>
> Increasing startup time by 33% seems like a bad tradeoff to me, then
> again, I know exactly how things work and am not likely to make the
> mistake you mention.

In the document I recommend that publishers of zsh configuration
frameworks (think ohmyzsh, etc.) not zcompile user rc files by
default.

FWIW, I zcompile my own rc files, although I do it in a way that
avoids issues caused by mtime and missing source files (I don't
mention the latter problem in the doc; basically, if you zcompile an
rc file and remove the source, the rc file will still be in effect).
The only downside I get from zcompiling is that aliases get expanded
differently but that's fine with me.