Problem width loading expl3-code.tex

[charlyms]

trafficstars

Hello, does anyone have an idea why latexml sometimes stucks at the point: | Digesting > Processing > Loading > Loading > Loading > Processing > Processing definitions C:/Users/.../.../l |ernel.tds/tex/latex/l3kernel/expl3-code.tex

[dginev]

Hi @charlyms ,

Yes, we are certainly aware of expl3 being slow. It is currently borderline unusable on texlive 2022 and older (~10 minutes per run) and completely unusable on texlive 2023 (~20 minutes of load time).

And that is on linux installations. You pay an additional slowdown penalty on Windows, which has a slower Perl interpreter.

There are 2 plans to address this in future latexml milestones:

• one is precompiling a format file for expl3-capable LaTeX, similarly to pdflatex
• A larger ongoing effort is entirely rewriting latexml in the Rust programming language

For now my best advice is to 1) try to avoid expl3 when possible and 2) use texlive 2021 or 2022 for optimal results.

[nschloe]

A larger ongoing effort is entirely rewriting latexml in the Rust programming language

:partying_face:

[orbita2d]

Can you not just save built artifacts for each package to a local directory? Surely better than a 20 min build time?

[dginev]

Can you not just save built artifacts for each package to a local directory? Surely better than a 20 min build time?

Yes, but not without making the right amount of preparatory work (see #2358 for an example of just one preliminary piece). There is merit to having a \dump-like capability in LaTeXML and @brucemiller already has a working prototype that could amortize the 20 minutes.

The 20 min build time is also a sign that LaTeX 3 support in LaTeXML is not properly tested on newer texlive versions (2023, 2024). There may be other regressions lurking there.

So the most sensible short term strategy is to "just" avoid such loads entirely for now.

[jghub]

new user here (2 days...): just for completeness, this problem is still present with texlive2024 installation on my OSX machine (texlive installed via macports) so this issue could also be tagged texlive2023ff ;). and the run time really is horrendeous ...

I am an (probably) ordinary latex user and far from knowing its inner workings, so: how would one "just avoid" expl3? I have no idea what it actually does (not tried, yet, to find out...), and by which package I am using in my documents (e.g. journal article manuscripts with the journals providing prescribed templates) it is requested/included...

[dginev]

@jghub on your question:

how would one "just avoid" expl3?

There is no productive way to avoid it entirely, if you want to depend on any actively updated texlive packages. Migrating to LaTeX 3 is very much the plan for the CTAN ecosystem, so the long-term expectation would be that tools like LaTeXML can support that kernel.

If you were a proficient user of LaTeXML who wanted to avoid the issue while using a new texlive, your option would be to add local .ltxml binding files to your project source directory, which would act as overrides to the bindings included with LaTeXML. An expl3.sty.ltxml file containing just a single line with

1;

Should act as a no-op alternative for that load. The tricky part is finding out which other packages now require expl3 support in texlives >2022, and avoiding them entirely (or creating custom bindings for them). I wouldn't recommend this approach for anything but quick testing.

And yes, as mentioned in earlier comments, we are painfully aware this is a serious problem going forward, in need of a good solution.

[jghub]

thanks for these clarifications. re

An expl3.sty.ltxml file containing just a single line with

1;

Should act as a no-op alternative for that load.

I tried this (putting such a file in the top-level dir of the latex document from where I execute latexml mydoc.tex) but seemingly this has no effect: latexml still starts "infinite processing" of expl3-code.tex. did I misunderstand how to do this?

in any case, thanks again for your response. I understand that it might take time until this issue can be straightened out in a clean way.

[dginev]

Right, keep adding such 1; files for anything else that exhibits a problem -- assuming all you want is to deactivate it completely. You'd need an expl3-code.tex.ltxml next.

[jghub]

ah I see, thanks. ok, that then leads to >100 errors (and thus a fatal error...). but I've got the idea. would need to better understand the whole machinery to make sensible use of this approach I guess (as you've already indicated :)).