[XeTeX] performance on Windows machines

Jonathan Kew jonathan_kew at sil.org
Tue Sep 12 10:17:59 CEST 2006


On 12 Sep 2006, at 8:16 am, Hans Hagen wrote:

> the texbook is not really representing the average document
>
> - there are no complex, time consuming macros involved
> - the font system is relatively simple
> - the document is coded in raw tex
> - no color, graphics etc are used

Yes, I realize it's not typical of today's documents; it's merely a  
file I sometimes run as an experiment, and as a quick check to see  
whether I've broken anything particularly badly!

> since pdftex and xetex share the same tex machinery,

In general, yes; though xetex uses 16-bit character codes and bigger  
catcode/lccode/sfcode/etc tables, which gives it a bigger memory  
footprint, bigger .fmt files, etc. So initialization takes a little  
longer, and cache misses are probably more common. It is also (by  
default) interpreting UTF-8 rather than reading raw bytes from the  
input, so there's the overhead of checking the byte values, even if  
they all turn out to be plain ASCII (yes, this is a small but  
measurable factor). So "xetex -no-pdf" runs slightly slower than  
"pdftex -output-format=dvi".

> the difference most
> indeed be related to the backend;

Right; and on balance pdftex will surely be more efficient in terms  
of raw CPU usage, as it generates the PDF directly from tex's  
internal memory structures, rather than encoding this as DVI and then  
reinterpreting the DVI codes and generating PDF.

Obviously there could be significant differences in how efficiently  
particular things (fonts, graphics, etc) are handled.

> the two processor approach is interesting since it's one of the few
> areas where tex can still be sped up

And this is what allows xetex to catch up with (and even overtake)  
pdftex on a multiprocessor machine. It's faster to generate DVI than  
to generate PDF (no need for all that font handling, for one thing!),  
and the overhead of PDF generation gets offloaded to a separate  
processor.

(Once you start handling complex OpenType layout features, though,  
all this usually gets swamped anyway!)

JK



More information about the XeTeX mailing list