Do the online LaTeX compilers use a TeX daemon to speed up their compilation?

Question

There seem to be quite a few fabulous web-sites now that compile LaTeX online.

I was wondering what techniques these sites used to speed up compilation of documents. It would seem they would be particularly interested in reducing the CPU load from loading the compiler, especially as many of the documents they would be asked to create would be relatively small.

In my experience it seems like the ordinary process for creating a relatively small document with LaTeX, especially XeLaTeX, seems to take a substantial amount of time starting the compiler (e.g. a couple seconds), and a relatively very modest amount of time running it (a few milliseconds).

It would seem then that one could gain tremendous improvements in performance for relatively small documents by running (PDF/Xe)LaTeX as a daemon that produced a number of documents without having to restart the process.

Others seem to have tried this, and it has been discussed (also) on Tex.SE before. The techniques seem to be somewhat dated, and in any case I couldn't get them to work on Linux with XeLaTeX (which just happens to be what I'm using).

Are any of the online compilers using a sort of TeX daemon to compile their documents in the background? Are there any other recent developments in this area? I happen to be personally interested in the XeLaTeX on Linux, but I would love to know more about what is happening in the LaTeX performance area.

There also seems to be quite a bit of discussion about pre-compilation (as seen under eg performance), but I tried it and the benefits do not seem to be as great as that of daemonizing the process (though I would stand to be proven correct!).

Are there other techniques these online services may be using to improve the response time of compilation?

Answer 1

I'm a cofounder at writeLaTeX.

We don't currently use a background daemon. Our backend uses pdflatex on Linux, so I can't say much about XeLaTeX on Windows (but XeLaTeX support is planned), but here's our experience.

The main factor that determines the compile time for a small document is whether the many source files for the packages it uses are already in the linux disk cache. (See http://www.linuxatemyram.com for an overview of the disk cache and some good links.)

That is, the first latex document you compile tends to be slow, because latex has to read all of those files from their various locations on your hard disk. But, when you compile the second document, the operating system has helpfully kept those files in main memory since it read them the first time, so reading them in again is much faster.

I also know that jpallen of ShareLaTeX now maintains the CLSI, which is open source, so you can see how that backend works. I don't think it uses a background service, either.

As far as I can see, the daemon-based approaches in the links you provided still work in principle, but I don't know whether they're still supported.

Answer 2

I don't know the techniques they use, however, I may be able to shed some light from a general systems viewpoint:

First and formost, pdflatex is a CPU-bound program (see Tips for choosing hardware for best LaTeX compile performance). On any modern operating system and hardware it should take less than a couple of milliseconds to start it inside a new process and this startup time should be insignificant in relation to the computational work done for the typesetting. Hence, even in a massive multi-user setting, the benefits of running it inside a preloaded daemon would be relatively small.

Most disk IO is related to a restricted set of files (the standard classes and packages), which therefore will reside in the buffer cache. However, on a standard server today, it would even be not a problem to cache all TexLive packages and fonts (hey, this are just a few GiB).

If hundreds or thousands of program instances run in parallel, their memory working sets would furthermore share large parts of the physical memory. Basically, all non-volatile memory (program code, constant data) is shared among all pdflatex processes. Under the hood, the operating system initially "shares everything" and transparently creates a private copy of each memory page only when a process attempts to write to it. So memory that is never written remains always shared.

To sum up: Given a modern hardware and operating-system environment, I would not expect signficant benefits by the daemon approach.