1

I'm compiling a small document (8 pp.) that has a lot of references (e.g. publication list). I am using TexShop 4.26 on Mac OS 10.14.2 (Mojave) and biber 2.10. I am running pdflatex > biber > pdflatex.

Everything is working but the running biber and then the second compilation with pdflatex are so slow!!!! It takes four to five minutes to compile with pdflatex the second time.

What should I be looking for?

Bernard
  • 271,350
spindoctor
  • 609
  • 3
    Since Biber writes the bibliography data to the .bbl file and LaTeX reads it on the next run, that is the file I would focus on. What size is the .bbl file? Do you have any works with extraordinarily many authors? Or anything else that could be out of the ordinary. (8 pages does not seem like the document could contain a lot of references, at least not for a definition of 'lot' that should slow things down so significantly. I just tested a 17-page document consisting only of a bibliography and the LaTeX run was fine. Usually the performance bottleneck is Biber itself.) – moewe Mar 29 '19 at 05:38
  • 1
    Is there anything special in your bibliography setup? Do you perform any expensive calculations on the fly? Is it possible to reproduce a similar issue with the file biblatex-examples.bib (which is pre-installed on your system, you can view the file at https://github.com/plk/biblatex/blob/master/bibtex/bib/biblatex/biblatex-examples.bib)? I'm going to stick my neck out and say that five minutes is too long for an eight-page document even on slightly older hardware (and Mac OS 10.14.2 sounds fairly recent). – moewe Mar 29 '19 at 05:44
  • I have solved my own problem. I had my publications saved in the same .bib file along with all my references. This created one huge .bib file. For the publication section, I had called \nocite{*} and then used keywords to print only my publications. That meant that biber was producing a .bbl file that had every single reference included in it.

    I used this solution (https://tex.stackexchange.com/questions/170316/nocite-for-single-bibdatasources-with-biblatex-biber) to figure out a way to make a separate .bib file with only my publications and use \nocite{*}[publications.bib].

     – spindoctor Mar 29 '19 at 17:53

1 Answers1

4

Usually the performance bottleneck for biblatex bibliographies seems to be the Biber run. At least that is what people mainly complain about (Why is biber so slow?, Why is Biber 2.8 so much slower than Biber 2.7?), but the LaTeX run is also impacted by certain effects (Why does biber increase compilation time of pdflatex runs dramatically (factor 2.8!!)?).

If the second LaTeX run in the LaTeX, Biber, LaTeX, LaTeX sequence is significantly slower than the first it is natural to look for the issue in the .bbl file that Biber created to pass bibliographic information on to LaTeX (see Question mark or bold citation key instead of citation number for a wonderful explanation of .bbl files; note that biblatex's .bbl files are a lot more abstract and complex than .bbl files generated by standard BibTeX, which basically just contain the text of the bibliography for typesetting). LaTeX has to process the entire .bbl file, so the larger that file is, the longer the LaTeX run will be. Of course this is not purely about file size: Certain things are more expensive (name lists, which are read as key-value pairs) than just literal fields (read as a simple \def assignment).

This becomes especially relevant if the .bbl contains many entries (maybe due to a \nocite) that are not explicitly \cited anywhere in the document and not printed in any \printbibliography due to filtering. In such a case there is not a lot of output, but potentially a lot of unused data. That data still needs to be processed and thus takes a lot of time and resources to get through.

Depending on how exactly the entries are to be filtered for inclusion in the bibliography, it might be possible to filter them with a sourcemap which means they don't make it to the .bbl file and don't inflate its size artificially. The following examples are from the biblatex documentation. Of course there are some filtering decisions that can not be taken on the basis of field contents alone and where document context plays a role. But if it is possible to filter with Biber's sourcemap than that is preferable in terms of performance for LaTeX runs.

\DeclareSourcemap{
  \maps[datatype=bibtex]{
    \map{
      \step[fieldsource=title, match={A Title}, final]
      \step[entrynull]
    }
  }
}

Would delete all entries whose field contains the string A Title.

\DeclareSourcemap{
  \maps[datatype=bibtex]{
    \map{
      \pernottype{book}
      \pernottype{article}
      \step[entrynull]
    }
  }
}

Would delete all entries that are not @books or @articles.

In theory other temporary files (mainly the .aux) could also cause a slowdown on subsequent runs. The commands from the .aux are not that computationally expensive, but still, adding more calls in the .aux will also increase compilation time.

moewe
  • 175,683