Check for compdump change with dat file

[ericbn]

containing more information, based on the data used by zsh4humans by @romkatv. The cost of checking that during startup was not significant when measured with the zsh-branch of zsh-framework-benchmark in the GitHub Action machine. The benefit is the end of worries about the compdump file being out-of-date.

[ericbn]

This is the result of the zsh-framework-benchmark in the GitHub Action machine:

framework	mean	stddev	min	max
zim	0.0503534	0.00056605	0.049274	0.052293
zim-branch1	0.0510828	0.0005732	0.049966	0.053003
zim-branch2	0.0510304	0.00040146	0.050223	0.052125
zim-branch3	0.0512581	0.00052467	0.050355	0.052803

These are the meaning of the different branches:

• zim: uses the master branch of the completion module, that simply does compinit -C -d ${zdumpfile} and relies on zimfw check-dumpfile for a later check that honestly does not work completely well. Because this solution is flawed, it made me consider and benchmark the solutions below.
• zim-branch1: uses the generate-dat-file branch of the completion module, that creates a dat file mostly meant to be later checked by zimfw check-dumpfile. This would result in a good check, but most of it is done later and requiring the user to run zimfw check-dumpfile.
• zim-branch2: uses the check-dat-file branch of the completion module, that creates and also checks the dat file. Because it solves the whole problem in one place, we won't need zimfw check-dumpfile anymore. This is the branch I'm proposing to be merged in this PR.
• zim-branch3: uses the compinit branch of the completion module, that does compinit -d ${zdumpfile} (without the -C), for comparison.

I saw different results in my Mid 2015 MacBook Pro with SSD using Zsh 5.9, with zim-branch2 taking 38% more time than zim. Also ran this in a very old Windows laptop with HD using WSL1 and Zsh 5.4.2, and zim-branch2 took only 8% more time than zim.

@romkatv, I want to include a thank you note in the README.md and "Copyright (c) 2020 Roman Perepelitsa" in the MIT LICENSE if we merge this. Should I also include something else?

@Eriner, since the idea was always to keep Zim as light as possible, please let me know your thoughts on this.

Thoughts and benchmarks for anyone wanting to contribute to the discussion are also more than welcome.

EDIT: To run the benchmarks for all branches locally, make sure you have an up-to-date clone of https://github.com/zimfw/zsh-framework-benchmark and then do:

$ git checkout zim-branch
$ source run.zsh -n 10 -f zim -f zim-branch1 -f zim-branch2 -f zim-branch3

[romkatv]

@romkatv, I want to include a thank you note in the README.md and "Copyright (c) 2020 Roman Perepelitsa" in the MIT LICENSE if we merge this.

I appreciate it.

[Eriner]

I have no issue with this if it fixes the issue. The negative effects of start speed usually happen when there are a lot of small files and slow IO (old machines with HDDs, rpis, other single-board computers). One file addition isn't a concern to me and I'm glad the issue is resolved.

Thanks for the tests and comparisons @ericbn, and thanks for the underlying fix @romkatv!

Does upstream zsh have an opinion on this issue, btw? It seems odd that this song-and-dance is required just for it to work like you'd expect.