# How to make compilation faster? [closed]

I have a rather large document (about 150~200 pages) with plenty of cross-references. I can, of course, use \include and \includeonly, but I do not only have new chapters, I also use \input for smaller pieces I have written (which are still rather long) and they should not invoke a clearpage. So, disabling those parts will additionally get plenty of (??).

Sure, I can get out the relevant pieces, but I don't like that type of workflow. Are there good references what might be a good workflow to write a PhD thesis or a book?

I am using a scons script to run the required programs often enough (biber as well).

The reason I compile I to see if it looks good now, or to make it easier for me to read the things I have typed. I am using emacs, so perhaps preview-latex can help me, but that seems to me as a rather ugly hack in the way it is generated (and slow). Is anybody aware of using MathJax for preview-latex? They would not have to go through the latex compiler.

But using these things still make the compile last way too long. So my question is perhaps a bit strange and displays my tremendous ignorance on these matters, but...

The question: I see there are many projects like LuaTeX, XeTeX and so on which seem to improve on one of the disadvantages of pdftex. Are there also versions which have a saner error handling? For instance, are there versions which do not require so many auxiliary files and store ".aux" in perhaps an SQLite DB? I can imagine that the user interactive part during compile was very useful when computers were slow and memory was expensive, but nowadays this does not seem so useful to me (and most editors seem to disable it...). Often, I have to delete the .aux because otherwise I keep compile errors after I made a mistake. Am I doing something wrong?

What is the big problem for having a better handling of errors in LaTeX? I am interested in the problem from a programming point of view, I would like to understand the compilation in more detail.

Last... Are there also drivers that compile into some kind of "intermediate format"? The thing would be that this should support the pdf features but still be rather easily readable, for the purpose of having at compile time the option to do a diff with the old code, study what needs to be regenerated and insert that part. In the end the page breaks could be regenerated, but if I am just working on the document a "lazy" compile which skips this step would be very useful.

I am not sure what kind of answer I am looking for. "You are doing it wrrrrong" is fine as well. Actually, that would be the best as then I would not have to start programming instead of working on my thesis and teach calculus 8-).

-

## closed as not a real question by Martin Schröder, Marco Daniel, clemens, Thorsten, Ian ThompsonOct 22 '12 at 11:39

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

Are you possibly including a lot of large graphics files? If so, adding the draft option will speed up compilation by inserting "dummy" images instead of the real ones. Do you have a lot of per-chapter bibliographies? If so, assuming they've been generated correctly once, you probably can dispense with re-generating them over and over again, and wait till the near-final version to (re-)create them. – Mico Oct 21 '12 at 14:51
– Werner Oct 21 '12 at 14:59
@Mico No graphics. But I do have chapter bibliographies. Are there methods that only regenerate new things and not the run the complete chain again? I am already using the draft mode, by the way. – Jonas Teuwen Oct 21 '12 at 15:01
you could add the draft option and just compile into dvi mode using latex myfile.tex; the dvi file is the "intermediate" file format you describe – cmhughes Oct 21 '12 at 15:32
@JonasTeuwen: How long is "too long"? Remember: The compilations of the TeXbook bei Knuth in 1986 probably took hours - now we can compile the TeXbook in seconds. – Martin Schröder Oct 22 '12 at 8:52