3 ms·

Can also use zcompile to further improve loading speed (not sure if measureable, but I did it for the sake of it).

cb321 4y ago
It is quite measurable. Some details. At the top of .zshenv zmodload zsh/datetime [[ -v ZSH_TIME_STARTUP ]] && t0=$EPOCHREALTIME and at the bottom of .zshrc [[ -v ZSH_TIME_STARTUP ]] && echo $[EPOCHREALTIME-t0] This is better than alternatives mentioned here which also time .zlogout - i.e. start up & shut down. Now, when I do something like (repeat 20 ZSH_TIME_STARTUP= zsh -il -c exit)|sort -g|head -n5|mnsd I get 0.03635 +- 0.00034 Now if I rm .zcompdump.zwc digraphs.zsh.zwc and then repeat the "mean,std.dev of best 5 out of 20" above, I get 0.07270 +- 0.00015 So, basically 2x faster start up time by just by doing zcompile on those two files. Also, if I re-run the (repeat..) then I get numbers within +- 2..3 std.devs. So, the numbers and run-to-run consistency all get along fine.
spockz 4y ago
How would you use zcompile? The help page reads to me I need to point it at a file. But which one? .zshrc?
- cb321 4y ago
  A good way to isolate which work is causing slowness is the PS4 variable. This is what is printed in "-x" tracing mode. E.g.: PS4='+$EPOCHREALTIME ' zsh -ilx -c exit 2>/t/zpro You need to have `zmodload zsh/datetime` loaded early for that to work..E.g. at the very top of your .zshenv. It's not hard to do a little post-processing script to have awk do entry-to-entry deltas on that /t/zpro file and then sort those to get a "seconds cmd" kind of report. Personally, I have found this more effective at identifying hotspots than the zprof mentioned in the article. EDIT: Caveat - There can be a bit of a Heisenberg style disturb what you are measuring effect from trace overheads. For example, the `_comps = (32 kiB report)` always shows up as the most expensive thing for me, but I think that 3.3ms comes mostly from the `-x` just printing the thing out after the timestamp or maybe formatting it for print. If I just do a t0=$EPOCHREALTIME before and echo $[EPOCHREALTIME-t0] after it takes only 1.0 ms in non-traced mode. So, 2.3/3.3 = 70% of the time is just the formatting/printing/-x work.

It is quite measurable. Some details. At the top of .zshenv zmodload zsh/datetime [[ -v ZSH_TIME_STARTUP ]] && t0=$EPOCHREALTIME and at the bottom of .zshrc [[ -v ZSH_TIME_STARTUP ]] && echo $[EPOCHREALTIME-t0] This is better than alternatives mentioned here which also time .zlogout - i.e. start up & shut down. Now, when I do something like (repeat 20 ZSH_TIME_STARTUP= zsh -il -c exit)|sort -g|head -n5|mnsd I get 0.03635 +- 0.00034 Now if I rm .zcompdump.zwc digraphs.zsh.zwc and then repeat the "mean,std.dev of best 5 out of 20" above, I get 0.07270 +- 0.00015 So, basically 2x faster start up time by just by doing zcompile on those two files. Also, if I re-run the (repeat..) then I get numbers within +- 2..3 std.devs. So, the numbers and run-to-run consistency all get along fine.

spockz 4y ago

How would you use zcompile? The help page reads to me I need to point it at a file. But which one? .zshrc?

cb321 4y ago
A good way to isolate which work is causing slowness is the PS4 variable. This is what is printed in "-x" tracing mode. E.g.: PS4='+$EPOCHREALTIME ' zsh -ilx -c exit 2>/t/zpro You need to have `zmodload zsh/datetime` loaded early for that to work..E.g. at the very top of your .zshenv. It's not hard to do a little post-processing script to have awk do entry-to-entry deltas on that /t/zpro file and then sort those to get a "seconds cmd" kind of report. Personally, I have found this more effective at identifying hotspots than the zprof mentioned in the article. EDIT: Caveat - There can be a bit of a Heisenberg style disturb what you are measuring effect from trace overheads. For example, the `_comps = (32 kiB report)` always shows up as the most expensive thing for me, but I think that 3.3ms comes mostly from the `-x` just printing the thing out after the timestamp or maybe formatting it for print. If I just do a t0=$EPOCHREALTIME before and echo $[EPOCHREALTIME-t0] after it takes only 1.0 ms in non-traced mode. So, 2.3/3.3 = 70% of the time is just the formatting/printing/-x work.