TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a simple document, about 20 pages long with some mathematics and a couple of tikz diagrams. I use biblatex and biber (0.9.9 MacTeX 2011) to compile my references, of which there are currently 2, with maybe 10 citations.

When using the bibtex backend the bibliography stage of my compilation takes under a second. Biber takes over 5 seconds to process exactly the same file.

I use TeXShop and with biber the console window appears but none of biber's command line output appears for at least 4 seconds.

Is there a problem with my setup or is biber slow by design?

EDIT: yes, it is slow every time. I've done some digging into the folders where biber unpacks its perl dependencies and I think TeXShop might be unpacking it every time. Perhaps something deletes the unpacked binary after each use.

The way I've made TeXShop use biber is to change the bibTeX engine field in the preferences to `biber'.

share|improve this question
The first time you run Biber, it has to unpack a lot of Perl stuff. Second and subsequent runs should therefore be a lot faster than the first run. Do you see this issue repeatedly? – Joseph Wright Apr 25 '12 at 10:34
@JosephWright -- no question it speeds up, but it still runs slower than bibtex. It's still worth it, given all the extra functionality, but there is a noticeable difference. (Same with luatex; and the two combined gives you time to grab a coffee for book-length projects.) – jon Apr 25 '12 at 15:18
@jon, granted I know it will be slower that bibtex, but I've a speedy SSD and the document is so small I suspect something else is at play. It blazes through the LuaLatex compilation in about 1s. – yun Apr 25 '12 at 15:20
On my system, Biber is certainly slower than BibTeX when run for example from the Terminal, with no graphical element and no unpacking (4.5 s versus 0.3 s for the test file biblatex-chem-acs). I'm not sure you can say it's 'deliberate', but BibTeX is a small program written in (I think) C whereas Biber is more complex and written in Perl. I'm not sure what you can do here unless you are volunteering to work on the Biber codebase. – Joseph Wright Apr 25 '12 at 15:33
I don't really see the point porting to a faster language - it's a batch program after all. You will never get something as fast as bibtex but with 80% more functionality ... Of course it could be done in C but it would be a hell of a job. – PLK Apr 25 '12 at 15:50
up vote 31 down vote accepted

It is slower than bibtex which is in C, even if you take into consideration the first run unpacking. Bear in mind that biber does a lot more than bibtex too. They are hardly comparable in functionality at all. Your tikz and maths should make no difference to biber. If your cache is getting deleted every time you run, this will make a huge difference. Easy to check this - delete the cache and run. Is the second biber run any faster?

The main overhead is sorting. It is a complex business, dealing with much more than bibtex - Unicode 7.0, direction per-field, case per field ... Next overhead is uniqueness processing. Again, complex. Bibtex probably does about 20% of what biber does. See the biber PDF manual to get a sense of its share of the biblatex work.

As of version 2.5 (currently in DEV), I have done some profiling with NYTProf. The majority of bibers time is spent inside the Unicode::Collate module (written in C), as one would expect as sorting is a main focus and it's expensive to do tailored UCA sorting (which bibtex doesn't even come close to doing). After some examining of the call stacks, I've done some some loop tidying for sorting calls and now biber 2.5 is about four times as fast as 2.4 and probably all earlier versions.

As mentioned in the doc, for performance testing, I use a 2150 entry, 15,000 line .bib file which references a 630 entry macro file with a resulting 160 or so page bibliography. In biber 2.4 this takes about 2 minutes to process. In the current 2.5 development version it takes about 28 seconds. This is almost the same now as when using the --fastsort option which doesn't use Unicode collation (so I may drop --fastsort since it is functionally far less useful and if there is no performance benefit, there no longer any point in it).

share|improve this answer
Thanks for the information. I'm not all that comfortable wiping files and folders from arcane /var directories. If someone could disambiguate the biber manual's description of where it gets unpacked for me I'll try deleting the cache. That should settle this once and for all. – yun Apr 25 '12 at 15:37
It's quite safe to delete the par-xxxxx directory – PLK Apr 25 '12 at 15:40
I just tested biber on a little file with and without deleting the cache. I can report that there is no problem with cache persistence, it's just slow. Thanks everyone. – yun Apr 25 '12 at 15:52
I will look more into optimisation at some point – PLK Apr 25 '12 at 15:58
Try the biber 1.0 beta -it has a --cache option to show the cache location now. You will need to be using biblatex 2.0 beta – PLK Apr 26 '12 at 14:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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