[dfc]

Can you give us any insight into how you plan on getting around this? It seems that publication quality typesetting and layout requires a certain level of CPU power, especially with complex graphics from TikZ/PGF and/or pstricks. Do you think your solutions will also help desktop users reduce the amount of CPU latex eats?

[jdleesmiller]

Good question. There's not much we can do at the LaTeX level, but writeLaTeX also has to send images of the pages back to browser, and we can improve that part of the process in quite a few ways.

[cben]

Perhaps it would help to checkpoint the compilation periodically, keyed by hash of input consumed so far, so when adding a word on page 100 you don't have to load all packages and recompile 100 pages.

- One approach is fork() processes (the tricky part being flushing all I/O and redirecting to separate files). This only works in RAM, which means active users & machine affinity, but I suspect storing checkpoints for long is useless anyway.

- Another approach is TeX's builtin memory \dump mechanism. This generates a file, so you could reuse flexibly, stuff in memcached etc. And easier to set up. But looking at mylatex.ltx I get the impression you can't \dump from a process that loaded a dump, so you'd have to start from initial tex and re-parse all of latex :-(. Perhaps still a gain, at least keeping one dump after the preamble?

The other half of the problem is getting the page(s) you want quickly without waiting for the whole document to compile. My impression is pdflatex output is not valid PDF until it's done. Less of a problem for writelatex which already does separate images?

[jdleesmiller]

Thanks for the suggestions! The fork() idea is very interesting --- I hadn't thought of that. Drop me a line at john at writelatex.com if you ever want to chat about tex stuff. :)