24

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 ), 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?

5
  • Which OS and IDE are you using? Compiling relatively short LaTeX documents takes less than a second on my Macbook Pro 2010, but substantially longer on my Windows 7 partition (both with TeXmaker).
    – jub0bs
    Mar 8, 2013 at 23:29
  • 1
    @Jucobs: Linux. The purpose of the question is (albeit not directly stated) relative to high performance compilations, where for example there may be several hundred to thousands of concurrent jobs every second. One would expect a LaTeX service provider to use elastic delivery such as Amazon EC2 or Linode. Memory is also a concern - every XeLaTeX instance can consume >100mb of memory, so keeping one instance with multiple compiles in memory would be very, very handy. Mar 8, 2013 at 23:34
  • Yes, I know, it was just a side question.
    – jub0bs
    Mar 8, 2013 at 23:42
  • @Jubobs: :) Incidentally I use VIM, for what it's worth. My code is bad enough — with an IDE it'd be a debacle. ;) Mar 9, 2013 at 0:02
  • 2
    I'm not sure we can answer this directly (only the people who run such services can). However, I think it's unlikely. The TeX daemon that I know does run as a service only does a subset of plain TeX as it needs to be robust against 'malicious' input. In particular, LaTeX uses \csname constructs for environments, and these are not tested carefully so can be used to execute something like \global or \bye. This will 'poison' the daemon, so it would be very risky to run an online service in this way.
    – Joseph Wright
    Mar 10, 2013 at 15:18

2 Answers 2

17

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.

2
  • 3
    Interesting, and welcome to TX.SX.
    – mafp
    Jul 3, 2013 at 22:20
  • Excellent answer, thanks for posting, and welcome to Tex.SE. :) I would love to know your experience with XeLaTeX; my limited experience is that it's somewhat more memory intensive than pdflatex, but otherwise they share performance characteristics. Jul 4, 2013 at 12:40
7

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.

You must log in to answer this question.

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