[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