I have a large notebook (~300 pages and growing at ~50 per month) with:

  • Deep hierarchy (I use parts, chapters, sections, subsections, subsubsections and paragraphs)
  • Document is broken into many parts (30-40 files in total) which are \inputted at all levels of the section hierarchy (some files are a whole chapter, some files are a single paragraph)
  • Many images and tables
  • A fair number of references with (\label and \ref)
  • hyperref
  • Most floats are anchored with H! because I don't want them to move
  • Lots of commands like \clearpage, \nolinebreak and \nopagebreak to fine tune typesetting
  • Large floats which contain blocks of text (and many overfull boxes)

Compiling this takes a few dozen seconds. This is fine most of the time, but if I need to fine tune the size of a picture (needing repeated compiles) the process becomes agonizingly slow. I know that the first step to speed things up is using \include, so parts that haven't changed don't need to be recompiled. But what's a good policy for deciding when to \include and when to \input?

Since I can't (unfortunately) \include everything, should I:

  • Always try to \include top level files and \input everything below that? This has less overhead (after I \include each chapter or part I can stop worrying and use only \input from then on) but if I am working on a very large chapter, it will kill most of my performance benefit.
  • Always try to \include the lowest level file, such as individual chapter or \paragraphs. The problem with this is that if a section S that was previously small enough to fit in one file needs to be split into files S1, S2 and S3 (with S2 and S3 nested inside S1), I now have to go back find where the \include was so I can turn it into \input, and \include the files S2 and S3 instead. Also, \includes force a pagebreak and mess up my layout.
  • \include somewhere in the middle. This is the most flexible option, but it is also the most work, since the previous issue of hunting down and shuffling \includes is now much worse.

What do I do? Is there a single optimal strategy for managing a large, complex Latex project?

  • I have used the package docmute to build course syllabai, handouts, lecture slides, quizzes for 5 courses in a single document (about 300 pgs). Pro: docmute allowed me to treat each file as a standalone document with preamble and allowed quick compile and correction of the subparts. Con: because ALL of the document had to have the SAME preamble and it only works with \input. The total compile is slow and the order of the packages in the preamble(s) is very critical. I made a common preamble and inputted that preamble into all of the files. Mar 30 '15 at 22:29
  • IIRC, the only difference is that \include forces a \newpage. Mar 30 '15 at 22:34
  • 3
    You cannot nest \includes. Also, this won't avoid recompilation. Just it lets you use \includeonly. For images, use standalone. Use the class when working on the image and then use the package for inclusion into your main file. \include something like a chapter i.e. a complete chunk which you might want to compile on its own.
    – cfr
    Mar 30 '15 at 22:38
  • @JohnKormylo I thought \included pages were somehow cached and not recompiled if the .tex is unchanged.
    – Superbest
    Mar 30 '15 at 22:41
  • 1
    I hope you are not using Most floats are anchored with H! as H! is a syntax error, you can not use ! with H Mar 30 '15 at 22:45

\include is typically only used for chapter level sectioning, specifically sections that are always forced to a new page. So you're description of changing sections at different levels between \include and \input rarely applies.

Using multiple input files below that doesn't really make any difference to TeX, there may be advantages for collaborative working or managing source control, but no really TeX specific difference between having multiple files or all in one file.

I assume you mean [H] from the float package rather than [!H] (which is a syntax error). This does of course disable LaTeX's main mechanism for avoiding bad page breaks but if you need to position and page break by hand, so be it.

It isn't clear why you should need to process a whole document to tine the size of a picture. If I understand what you mean you should only need to do it once, and so long as you have a test document with the right size text block and some dummy text you should be able to do that in a one-page document before dropping it into your main document.

  • Does this mean that there is no perceptible compilation speed difference between a monolithic file and a file that uses \input to assemble itself? Is there a question that I've missed that deals with this?
    – A Feldman
    Feb 3 '18 at 17:34
  • 1
    @AFeldman it depends on your file system and the size of the document. There is a cost to including a file, but unless you are including thousands of separate chapters it is unlikely to make any difference in practice, and anyway the overhead is similar to that of using a package, do you worry if you load four packages rather than three? Feb 3 '18 at 19:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.