24

Looking at what computers can do when it comes to presenting graphics (think games, graphical user interfaces, and so forth), it almost comes of as a surprise to me that I often have to wait for several minutes for complex LaTeX files with a lot of tables and figures to compile.

Why doesn't LaTeX compile faster? Is there some theoretical bottleneck when it comes to typesetting systems? Is it dependent on old code that can't be made to run faster without rewriting it completely? Haven't optimization been the focus of the developer team?

Improve this question
17
  • 4
    TeX is pretty fast on 'plain' text, and the LaTeX format doesn't add a lot to that: on a modern system you'll output several pages per second. Once you start doing complex calculations in macros, things get a bit more tricky. But without an idea of the type of document you are talking about, it's hard to say.
    – Joseph Wright ♦
    Aug 22, 2018 at 15:48
  • 6
    Remember that Kunth optimised TeX as much as possible to make it workable at all on late 1970s machines (minutes per page, of course), and the LaTeX kernel is highly-optimised based on resources available in 1994-ish.
    – Joseph Wright ♦
    Aug 22, 2018 at 15:51
  • 6
    LaTeX’s speed on today’s machines is as impressive as any other program’s, if you take into due account the huge amount of processing it has to do, being a (pseudo-)language entirely based on macro expansion. I remember the epic days (mid-90s) when the list of the outputted pages [1] [2] [3] [4]… looked like a worm slowly making his way across OzTeX’s window on my 68k-powered Macintosh Classic (bought in 1992) at the pace of roughly one page per minute… And there was no TikZ in those years!
    – GuM
    Aug 22, 2018 at 17:50
  • 3
    You could ask the same question about MS Word. Why is it so bloated and slow? This is hardly a unique problem.
    – jpmc26
    Aug 22, 2018 at 23:56
  • 1
    @GuM If I compare an old computer game from the mid-90s with a modern computer game, I'd say that the perceived difference is several orders of magnitude larger than the difference in LaTeX processing speed. Compare, for example, Battle Arena Toshinden (which was released for Playstation in 1995) with Battlefield V.
    – Speldosa
    Aug 23, 2018 at 11:08

1 Answer 1

Reset to default
31

The "slow" compilation speed of TeX has two main reasons:

  • It cannot parallelize. Games, GUIs etc. (what you refer to) do use multi-threading to speed up their execution. Because TeX builds up pages gradually (with counters, …) this is not an option and there are some questions about this aspect on the site (see e.g. here), apart from those asking about using the GPU (see e.g. here).
  • TeX is a macro expansion language. This kind of "programming" is not necessarily the fastest, but the developers (not engine-wise, but format-wise) try hard not to impose any slow-downs here. That's why some kernel code looks a bit cryptic. And concerning the engines optimization is one of the main concerns.

Just to back up the second point: A primary cause of slow compilation is the general understanding what TeX should do for you. Whenever you load PGF/TikZ or pstricks or something along these lines you essentially use TeX for something it has not been designed for. TeX should do mathematical and text typesetting (and it does that well), it should not produce complex graphics with shadows, draw ducks, plot functions or anything like this. There is a reason TikZ support externalization because this reduces the computations the macro layer has to do on each run.

At some point in history, there were attempts to write a modern TeX engine (NTS, ExTeX, …) – those two in Java – which should be fast and maintainable. But even these "modern" engines are single-threaded and cannot compete with the Web/C driven engines in terms of performance. Even LuaLaTeX as "modern real-world" engine cannot compete with pdflatex on simple documents.

Improve this answer
11
  • 3
    I don't think ExTeX was ever meant to compete in performance terms with the WEB/Web2c: Knuth's code is fast.
    – Joseph Wright ♦
    Aug 22, 2018 at 15:50
  • 1
    @JosephWright You're right, I edited that part to express that they should implement modern concepts and even they did not make the engines faster.
    – TeXnician
    Aug 22, 2018 at 15:53
  • 2
    @AndréC Yes, you can use parallelization for externalized TikZ graphics (that's what TikZ actively encourages by providing the make target). But this is an extra step before compiling, it won't affect the speed of the main compilation (apart from not building the graphics due to the reduced amount).
    – TeXnician
    Aug 22, 2018 at 20:18
  • 16
    I think this explanation is wrong: the gradual building of pages isn’t at all the reason that LaTeX can’t be parallelised. In fact, you could trivially lay out independent paragraphs, their layouting is mostly completely independent. The major issue is instead that any piece of code can redefine subsequently used macros in such a way that would completely change their layouting. That being said, this could still be parallelised by performing speculative layouting and redoing the layout in the (exceedingly rare) cases that previous code changes any macro’s meaning.
    – Konrad Rudolph
    Aug 22, 2018 at 20:56
  • 3
    @KonradRudolph I would not call that trivial, especially considering that your independent paragraphs may themselves break pages, making it necessary for such a parallel run to know about even/odd pages and many other oddities. What I meant was the point with the counters as an example of code that does change unexpectedly (think about roman page numbers followed by arabic ones). Concerning speculative layouting I agree that this would be an interesting approach and it would be interesting to see some research on this (do you know about any?).
    – TeXnician
    Aug 23, 2018 at 5:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .