> Taco Hoekwater wrote:

Hans Hagen wrote:
anyway .. i cannot comment on runtimes as xetex on my windows box runs
too slow (caching issue) and all examples are slow, no matter how i
specify fonts so i will not look into the code till that gets fixed first

The example with the typescript seems logical to me: a typescript does
much work beforehand, so I assume SimSum is loaded multiple times.

I am trying the AdobeSong example as we speak, there surely seems
something wrong there.

let's start with saying that I have no intention to optimize mkii for xetex as we decided some time ago (at the context meeting) that we would freeze mkii; so, if things run acceptable that's ok for me; we're also not going to optimize any further for pdftex any more unless i need it in a high performance project -)

when i delete my font.conf file (i.e. forget about names but only allow files) i can run xetex with reasonable performance

some timing:

% 64 sec xetex, 11 sec luatex (56 sec xetex when \nobigmath)


\dorecurse{10000}{{hello {\switchtobodyfont[myzhfont] 你好}}\par}

% 67 sec xetex, 11.5 sec luatex

\dorecurse{10000}{{hello {\switchtobodyfont[myzhfont] 你好}}\par}

% 5 sec xetex, 7 sec luatex

\setupbodyfont[myzhfont]  \dorecurse{10000}{{hello {你好}}\par}

now, in practice one will not switch complete bodyfonts so often, so something like

\setupbodyfont[myzhfont]  \dorecurse{10000}{{\bf hello {你好}}\par}

is more realistic (taks .5 sec more in xetex)

as taco mentioned, switchtobidyfont does way more than just switching a font like checking current state which involves checking fontclass, size, style etc and setting up font parameters for each case, as well as setting up math; fonts, when not yet set, will be loaded but that happens only once so that can be kind of neglected

the differences between mkii and mkiv have several reasons:

= mkiv has a more efficient font system as no encodings, mappings, one math family etc are involved and as such is much faster (less comma list processing, less checking, less mapping and encoding switches)

= in mkii there is a relationship between fonts, languages etc an dall need to be (re)synced since anything can have changed; i'm pretty sure that context does much more here than latex because we cater for mixed typefaces, mixed languages, encodings, etc and all combinations that can occur

= mkiv code has been optimized in the process so that might also count a bit (but not that much in real situations)

= mkiv can use traditional traditional fonts but does that in a special way by turning then into wide fonts which is also more efficient

now, since xetex runs on top of mkii it caries some overhead from traditional fonts

if we accept some limitations (i.e. stupify context mkii a bit) we can gain some speed (we can probably also load some less code then), for example




saves 20 sec on the 10K (irrealistic anyway) run but then we definitely need to make typescripts xetex specific and make sure that no encoded font files are used any longer

The question is ... does it pay off for me (as i have to do it in order to make sure we don't mess up things for pdftex) to spend time on this?

Probably not.

(Concerning timing: forget about comparing to latex as in practice much more is involved like page building etc. There are subsystems in context where i could squeeze out yet another .1 second just to see it become noise on real runs.)


                                          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
If your question is of interest to others as well, please add an entry to the 

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net

Reply via email to