Hi, Zsh offer neat function zcompile to compile functions/scripts to bytecode. Providing compiled functions from fpaths would be a good idea, Debian does it for quite some time. Find patch attached with zcompile-functions useflag. piotr@sabre ~ % strace zsh --login 2>&1 | grep -E 'open\("/usr.*zwc' open("/usr/share/zsh/5.0.2/functions/Calendar.zwc", O_RDONLY) = 3 open("/usr/share/zsh/5.0.2/functions/Chpwd.zwc", O_RDONLY) = 3 open("/usr/share/zsh/5.0.2/functions/Completion.zwc", O_RDONLY) = 3 open("/usr/share/zsh/5.0.2/functions/Completion.zwc", O_RDONLY) = 3 open("/usr/share/zsh/5.0.2/functions/Calendar.zwc", O_RDONLY) = 3 open("/usr/share/zsh/5.0.2/functions/Chpwd.zwc", O_RDONLY) = 3 open("/usr/share/zsh/5.0.2/functions/Calendar.zwc", O_RDONLY) = 3 open("/usr/share/zsh/5.0.2/functions/Chpwd.zwc", O_RDONLY) = 3 open("/usr/share/zsh/5.0.2/functions/Completion/AIX.zwc", O_RDONLY) = 3 open("/usr/share/zsh/5.0.2/functions/Completion/Base.zwc", O_RDONLY) = 3 open("/usr/share/zsh/5.0.2/functions/Completion/Base.zwc", O_RDONLY) = 3 Running other functions like 'zargs' load Misc.zwc etc. Reproducible: Always
Created attachment 362812 [details, diff] Ebuild patch.
Is there no better way to do it? I really don't want to add an awk script like that to the ebuild.
Wel, even if it looks hacky it pretty much what debian do, also other ebuilds does have awk. If you find better way how to get fpaths from zshpaths.h to loop over them with zcompile, that would be great but so far I found none.
(In reply to Piotr Karbowski from comment #3) > If you find better way how to get fpaths from zshpaths.h to loop over them > with zcompile, that would be great but so far I found none. The better approach would be to get upstream to maintain something that does this in their build system. Also, do you have any benchmarks on how much this speeds things up?
No benchmarks. And I debt that upstream will do it, if the awk would be moved to Makefile's target as a patch so 'make install' would run zcompile would it work for you better?
I added an alternative code using only "find" and zsh itself to the zsh ebuild in the mv overlay. If there is interest, I can also eliminate "find", but sys-apps/findutils is a system package, anyway. However, independently of which code is chosen, there is a problem with timestamps: zsh uses *.zwc files only if they are newer than the directory/files they refer to. Unfortunately, portage can produce newer filestamps for new directories when merging to the live filesystem. So it is also necessary to touch the *.zwc files in pkg_postinst to guarantee that they are newer than the rest. A few minutes ago, I added the latter to the zsh ebuild in the mv overlay. (The two relevant functions are zcompile_dirs() and touch_zwc() respectively). (In reply to Tim Harder from comment #4) > > The better approach would be to get upstream to maintain something that does > this in their build system. This would not solve the timestamp issue. Moreover, I doubt that upstream would accept such a major change, since it would make the build system much more complex: For instance, calling zcompile is not possible when cross-compiling. BTW, a similar remark holds also for producing help files; apparently upstream has no interest to include this into their build system (probably, because it requires certain tools to run properly on the building machine). I remind you that also for the latter corresponding extensions of the ebuild are in the mv overlay (bug 431402). > Also, do you have any benchmarks on how much this speeds things up? Do not trust a benchmark you haven't cheated yourself ;) I doubt that it is much, but the compiled files do not take much space, either, so why not give the user the possibility to slightly balance space vs. time requirements.
You run zcompile in ebuild. Does in your system portage uses zsh for ebuilds?
(In reply to Piotr Karbowski from comment #7) > You run zcompile in ebuild. > Does in your system portage uses zsh for ebuilds? This happens in src_install(), and the freshly built zsh ($ED/bin/zsh) is called by path to execute this code. Of course, this will break if this freshly built zsh cannot be executed on the building system (e.g. when crosscompiling for a different architecture, only): This is why it is necessary to make the whole code optional.
(In reply to Martin Väth from comment #6) > I doubt that it is much, but the compiled files do not take much space, > either, so why not give the user the possibility to slightly balance space > vs. time requirements. If the benefits are few, I have little interest in maintaining such things right now probably for similar reasons as upstream (same goes for bug 431402).
(In reply to Tim Harder from comment #9) > I have little interest in maintaining such things There is not much to maintain: The code is already written, so you can just put it into the ebuild and keep it there. It is not to be expected that e.g. the call of zcompile changes in future versions of zsh. If users have issues like e.g. for crosscompiling they can simply disable the useflag - this is not rocket science. Thinking it over, one should probably not auto-enable the useflags to have pure upstream's default (which AFAIK is gentoo's policy). This prevents faulty bug-reports from people who are not reading the non-crosscompiling condition in the useflag-description. > same goes for bug 431402 An interactive help is not a "small benefit", but I bet for many users a _necessary condition_ to try zsh seriously as an interactive shell (at least, it was for me: Having to decide between bash's interactive "help" and some new features which are almost unusable without an interactive help, the decision was simple. Only months later, I heard that something like "help" exists also in zsh, but having to install it separately for each of my users sounded strange, and moreover, the script to generate the files did not work out-of-the-box; so again, I was back to bash. I bet, it is similar for many other potential users)
I have brought both issues upstream; the discussion can be read on the zsh-devel mailainglist. Concerning *.zwc files, there were conjectures that it might even slow down things if you have some huge binary blobs instead of rarely used tiny source files. But it seems nobody has benchmarks, even whether *.zwc files help at all. Generally, there does not seem much interest to include something for a doubtful effect if there are no benchmarks. Concerning the help directory, a patch is preliminary accepted which will install the help directory to /usr/share/zsh/$ZSH_VERSION/help; if the patch goes into the released tarball, it might be necessary in the ebuild to prepend $EPREFIX to this path with the new configure option --enable-helpdir.
(In reply to Martin Väth from comment #11) > I have brought both issues upstream; the discussion can be read on the > zsh-devel mailainglist. Thanks for doing this. > Concerning *.zwc files, there were conjectures that it might even slow down > things if you have some huge binary blobs instead of rarely used tiny source > files. But it seems nobody has benchmarks, even whether *.zwc files help at > all. > Generally, there does not seem much interest to include something for a > doubtful effect if there are no benchmarks. My thoughts are the same. > Concerning the help directory, a patch is preliminary accepted which will > install the help directory to /usr/share/zsh/$ZSH_VERSION/help; if the patch > goes into the released tarball, it might be necessary in the ebuild to > prepend $EPREFIX to this path with the new configure option --enable-helpdir. Sounds great.
Closing this as won't fix at least until someone shows that there is a decent benefit to supporting this. Please reopen when you have reproducible benchmarks showing potential gains.
