[XeTeX] performance on Windows machines

Hans Hagen pragma at wxs.nl
Tue Sep 12 11:49:46 CEST 2006

Jonathan Kew wrote:
> 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  
this may take some more time, but doing the utf in macros is definitely 
slower -)

> 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.
it depends, dvipdfmx is pretty fast and has a different way of dealing 
with fonts; i would not be surprised if dvipdfmx's backend is faster 
than pdftex's but it's probably compensated by the intermediate data 
> 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.
sure, but nowadays we need more than just text and dvi can only handle 
that by means of specials which then must be interpreted
> (Once you start handling complex OpenType layout features, though,  
> all this usually gets swamped anyway!)

indeed -) same for hz in pdftex. features and quality have their price; no problem 


                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl

More information about the XeTeX mailing list