现在似乎有不少很棒的网站在线编译 LaTeX。
我想知道这些网站使用了什么技术来加速文档的编译。看来他们特别想减少加载编译器的 CPU 负载，尤其是因为他们需要创建的文档很多都比较小。
根据我的经验，使用 LaTeX（尤其是 XeLaTeX）创建相对较小的文档的普通过程似乎需要花费大量时间来启动编译器（例如几秒钟），并且运行它所需的时间相对较少（几毫秒）。
由此看来，通过运行 (PDF/Xe)LaTeX 作为守护进程来生成大量文档而无需重新启动该进程，可以大大提高相对较小文档的性能。
其他人似乎也尝试过这种方法，而且讨论 （还）之前在 Tex.SE 上尝试过。这些技术似乎有些过时了，而且无论如何我都无法让它们在 Linux 上使用 XeLaTeX（我正好在使用它）。
是否有任何在线编译器使用某种 TeX 守护程序在后台编译其文档？该领域还有其他最新发展吗？我个人恰好对 Linux 上的 XeLaTeX 感兴趣，但我很想知道更多有关 LaTeX 性能领域正在发生的事情。
关于预编译的讨论似乎也相当多（例如表现)，但我尝试过它，其好处似乎不如将进程守护进程化那么大（尽管我的观点是正确的！）。
这些在线服务是否可能使用其他技术来改善编译的响应时间？
答案1
我是写LaTeX。
我们目前不使用后台守护程序。我们的后端在 Linux 上使用 pdflatex，因此我无法透露太多有关 Windows 上的 XeLaTeX 的信息（但计划支持 XeLaTeX），但以下是我们的经验。
决定小文档编译时间的主要因素是它使用的软件包的许多源文件是否已经在 Linux 磁盘缓存中。（见http://www.linuxatemyram.com了解磁盘缓存的概述以及一些有用的链接。）
也就是说，您编译的第一个 latex 文档往往比较慢，因为 latex 必须从硬盘上的不同位置读取所有这些文件。但是，当您编译第二个文档时，操作系统会将这些文件保存在主内存中，因为它第一次读取它们，所以再次读取它们会快得多。
我还知道 ShareLaTeX 的 jpallen 现在维护临床实验室标准协会，它是开源的，所以你可以看到后端是如何工作的。我也不认为它使用后台服务。
据我所知，您提供的链接中的基于守护进程的方法在原则上仍然有效，但我不知道它们是否仍然受支持。
答案2
我不知道他们使用的技术，但是，我可以从一般系统的角度阐明一些问题：
首先，pdflatex是 CPU 密集型程序（参见选择硬件以获得最佳 LaTeX 编译性能的技巧)。在任何现代操作系统和硬件上，在新的进程中启动它应该只需要不到几毫秒的时间，而且这个启动时间相对于排版所做的计算工作来说应该是微不足道的。因此，即使在大规模多用户设置中，在预加载的守护进程中运行它的好处也相对较小。
大多数磁盘 IO 与一组有限的文件（标准类和包）有关，因此这些文件将驻留在缓冲区缓存中。然而，在当今的标准服务器上，缓存甚至不成问题全部TexLive 包和字体（嘿，这只是几 GiB）。
如果数百或数千个程序实例并行运行，它们的内存工作集还会共享大部分物理内存。基本上，所有非易失性内存（程序代码、常量数据）都由所有pdflatex进程共享。在底层，操作系统最初“共享所有内容”，并且仅在进程尝试写入时才透明地创建每个内存页面的私有副本。因此从未写入的内存始终保持共享状态。
总结一下：鉴于现代硬件和操作系统环境，我不会指望守护进程方法会带来显著的好处。