bug#64827: Texlive has become slow

[Nicolas Goaziou]

Hello,

Andreas Enge <andreas@enge.fr> writes:

> However, it has become extremely slow. When compiling a 42 page document:
> real  0m22,757s
> user  0m7,243s
> sys   0m15,370s
> Before it even outputs the first page of the document, I get pages and
> pages of screen output looking like lisp code:
> (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amstext.sty 
> (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) 
> (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) 
> (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) ...
>
> This is compared to before:
> real  0m1,426s
> user  0m1,191s
> sys   0m0,113s
> Where the lisp style lines look like this:
> (/gnu/store/m2hpk7ycdqj6n1nbjnd3d4l088m79smx-texlive-texmf-20210325/share/texmf
> -dist/tex/latex/amsmath/amstext.sty
> (/gnu/store/m2hpk7ycdqj6n1nbjnd3d4l088m79smx-texlive-texmf-20210325/share/texmf
> -dist/tex/latex/amsmath/amsgen.sty))
>
> The difference is that before, /home/enge/.guix-profile/share/texmf-dist
> was directly a symbolic link into the store. Now it is a directory, and
> each file in it is its own symbolic link to a file in the store, and
> resolving them apparently takes a lot of time.

Interesting!

> I am confused as to why this happens.
> /home/enge/.guix-profile/share/texmf-dist contains 28 symbolic links,
> 26 of which point to directories and 2 to files (ls-R and README) in
> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/
> Then there is the "physical" directory web2c. It contains 47 separate
> symbolic links to files and directories in
> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/web2c.
>
> I do not understand why not the complete texmf-dist is a symbolic link
> as before, as the content seems to be the same, which should be handled
> during the profile creation.

Monolithic TeX Live is (and always was) unrelated to profiles.

> Maybe because of this in the definition of the texlive package:
>       ;; Build the union of texlive-bin-full and texlive-texmf, but take the
>       ;; conflicting subdirectory share/texmf-dist from texlive-texmf.

This was exactly the same before "texlive-team-next" merge. I just
renamed `texlive-bin' as `texlive-bin-full'.

> What is the role of texlive-bin-full?

`texlive-bin-full' should be equivalent to `texlive-bin' before the
merge. It contains all binaries, and all scripts.

> Why does it contain share/texmf-dist?

I think scripts in "bin/" are symlinks to real scripts in
"share/texmf-dist".

> The basic architecture was to separate the binaries in texlive-bin (which
> needed compilation) from the tex files in texlive-texmf (which mainly needed
> copying, plus the black tex magic of format and font map creation), and
> their union was texlive.

This should still be the same. The main difference is that `texlive-bin'
was renamed `texlive-bin-full'. Any other change was probably not intended.

> My impression is that
> commit 19fd1004138b60c4479d7516aa0cee261c0b6b57
> Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> Date:   Mon Jun 26 12:00:51 2023 +0200
>     gnu: Externalize libkpathsea in texlive and texlive-bin.
> poses problems. Which problem is it supposed to solve?
>
> What is the idea of the new architecture? Having texlive-libkpathsea,
> texlive-bin and texlive-bin-full, all the three with very long package
> definitions, looks very complex to me.

It is not. Maybe the comment at the beginning of "tex.scm" would help
you understand it better. In a nutshell `texlive-bin' is for modular TeX
Live, whereas `texlive-bin-full' is for monolithic TeX Live. Both rely
on `texlive-libkpathsea', which can also be used to build other
executables (such as xindy) and remove them from `texlive-bin'.

> Would it be possible and make sense to revert this commit?

I don't think so, per above. This commit, which may be imperfect, is
essential to the modularization of the TeX Live system.

> I considered opening a new bug, since this one looked distinct from
> not being able to install texlive-biber; but I wonder if texlive-biber
> is not simply a symptom of the same problem.

I don't think the issue is related to `texlive-biber'.

> The error message is
> updmap: open() failed: No such file or directory at 
> /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap 
> line 2159.
> updmap [ERROR]: The following map file(s) couldn't be found:
> updmap [ERROR]:       dvips35.map (in builtin)
> updmap [ERROR]:       pdftex35.map (in builtin)
> updmap [ERROR]:       ps2pk35.map (in builtin)
> updmap [ERROR]: Did you run mktexlsr?
>
> Notice the location of the updmap script. The one in my profile points to
> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/bin/updmap
> of the texlive package and the missing .map files are there at
> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/fonts/map/dvips/tetex/dvips35.mapand
>  so on.

Profile hook `texlive-font-maps' is triggered by modular TeX Live, i.e.,
any "texlive-" prefixed package in the profile. If you don't install
any, it should not be run.

When it is run, however, it uses tools from modular TeX Live, not from
monolithic TeX Live.

I think the issue here may be that you are conflating the two TeX Live
systems currently provided by Guix, i.e., you both install `texlive' and
some "texlive-" package.

> So my impression is that the new way of packaging breaks the monolithic
> texlive package, and that the texlive-biber package by using the
> texlive-build-system has become incompatible with the monolithic texlive.
> This comes from commit
> commit 3aeca58073eff8b7a835f6492e735dd152d9dc99
> Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> Date:   Mon Jun 19 14:43:56 2023 +0200
>     gnu: biber -> texlive-biber.
> which moves from perl-build-system to texlive-build-system.

Coming from modular TeX Live, `texlive-biber' is certainly incompatible
with monolithic TeX Live, which, being monolithic, is expected to
include "biber" executable anyway.

Basically, if you install `texlive' package, you probably shouldn't
install any "texlive-" prefixed package. If, for some reason, you do,
you should ensure "texlive-" prefixed packages form a coherent system,
i.e., they are expected to provide some collection or scheme.

Regards,
-- 
Nicolas Goaziou