[svat]

• As a rough rule of thumb, TeX can do about 1000–3000 pages a second on today's computers.[1] This is for a (presumably typical) book that was written in plain TeX.

• So if your LaTeX document is taking orders of magnitude more than about a millisecond a page, then clearly the slowdown must be from additional (macro) code you've actually inserted into your document.

• TeX is already heavily optimized, so the best way to make the compilation faster is to not run code you don't need.

• Helping users do that would be best served IMO not by writing a new typesetting engine, but by improving the debugging and profiling so that users understand what is actually going on: what's making it slow, and what they actually need to happen on every compile.

To put it another way: users include macros and packages because they really want the corresponding functionality (and everyone wants a different 10% of what's available in the (La)TeX ecosystem). It's easy to make a system that runs fast by not doing most of the things that users actually want[2], but if you want a system that gives users what they'd get from their humongous LaTeX macro packages and yet is fast, it would be most useful to help them cut down the fluff from their document-compilation IMO.

---

[1] Details: Try it out yourself: Take the file gentle.tex, the source code to the book "A Gentle Introduction to TeX" (https://ctan.org/pkg/gentle), and time how long it takes to typeset 8 copies of the file (with the `\bye` only at the end): on my laptop, the resulting 776 pages are typeset in: 0.3s by `tex`, 0.6s by `pdftex` and `xetex`, and 0.8s by `luatex`.

[2] For that matter, plain TeX is already such a system; Knuth knew a thing or two about programming and optimization!

[pdw]

I never got deep into TeX, but I browsed the code at one time and some of what I found seemed utterly insane to me. For example, it includes an IEEE floating point implementation, based entirely on TeX string expansion [1]. I don't know if it is widely used, but I'm not surprised by slow LaTeX compiles anymore.

You say "TeX is already heavily optimized", but that's only true for the layout engine. The input language is entirely based on macros and string expansion. That's fine if you're only going to use it for a bit of text substitution. But as a programming language it's inherently slow. (To be fair, I believe Knuth expected that large extensions, such as LaTeX, would be implemented in WEB.)

[1] https://github.com/latex3/latex3/blob/main/l3kernel/l3fp-bas...

[svat]

That's precisely my point: the slowness comes not from TeX but from the LaTeX macro packages that the user has included on top. And if you want to make things faster for the user, you don't have to replace TeX (which is already plenty fast); you have to replace the macro packages or provide faster alternatives.

If you're going to create a new system with a new way of doing things (i.e. not using the existing popular LaTeX macro packages), then you can already do that on top of TeX, by just not using those packages! (Use LuaTeX and program in Lua instead of via TeX macros, or do the programming outside and generate the TeX input, or whatever.)

What I'm proposing is that the hard/worthwhile problem is to take real users' real LaTeX documents and give them ways of profiling (what inefficiently written macro packages are making this so slow, because surely it's not the typesetting) and replacing the slow parts.

[nextos]

This is a topic I have been interested in for a while. Is it viable to compose fancy large documents in plain TeX without a lot of effort replicating functionality provided by LaTeX (if your requirements stay constant)?

I am a heavy user of the memoir class, and I have always suspected moving to plain TeX would not be that hard. However, the fraction of users doing this seems pretty slim so modern TeX workflows do not seem really well documented.

[grayclhn]

I’ve tried. Coauthors and journal requirements were my limiting factors, not anything inherent to the typesetting engines…

These days (in industry) I manage to use pandoc markdown to word for everything (for similar reasons), which is even more limiting than plain TeX. You learn to write around the limitations pretty quickly. :)

[ta988]

For a dissertation you often have diagrams and bibliography this is taking a while. Even my resume takes more than 1s a build because of that.

[nerdponx]

How does LaTeX compare to XeTeX, ConTeXt, and LuaTeX in compilation speed?

[reknih]

This is not really a meaningful comparison: You have your TeX compiler (pdfTeX, XeTeX, LuaTeX, and the older e-TeX) that takes a document in some format and produces a PDF or DVI. In my tests (that did not include e-TeX) pdfTeX tends to be the fastest here, but sometimes you need modern fonts, so you have no choice but to use the other two.

The TeX compiler then loads a format like plain TeX (which the above commenter uses), LaTeX, or ConTeXt. The format defines what macros are available. LaTeX adds a package system, as does ConTeXt (modules) so you can import even more macros on-demand. These TeX formats differ in scope and thus speed, LaTeX tends to be a bit heavier but what really weighs it down are the myriad of packages it is usually used with.

Many TeX distributions will define aliases like pdflatex in your path such that you can preload pdfTeX with the LaTeX format, but they are not really separate compilers.

[nerdponx]

But XeTeX and LuaTeX are still billed as "end-user-facing" systems, alternatives to LaTeX and ConTeXt. I appreciate the distinction between the actual typesetting engine and a macro library layered on top, but as someone who has only ever used LaTeX I would definitely be interested in a thorough comparison of their capabilities, speed, user experience, etc. One can of course include plain TeX itself in such a comparison!