ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <pragma@wxs.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: XeConTeXt bug report I: strange benchmark
Date: Tue, 12 May 2009 13:02:36 +0200	[thread overview]
Message-ID: <4A09574C.6050201@wxs.nl> (raw)
In-Reply-To: <4A094C71.3040503@elvenkind.com>

 > 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)

\setupbodyfont[myzhfont]

\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

\def\updatefontparameters
   {\edef\@@fontfeatures{\truefontdata\fontfile\s!features}%
    \edef\@@fontskewchar{\truefontdata\fontfile\s!skewchar}}

\def\setfontcharacteristics
   {\updatefontparameters
    \the\everyfont}

\let\synchronizepatternswithfont\relax

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




-----------------------------------------------------------------
                                           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 Wiki!

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
___________________________________________________________________________________

  parent reply	other threads:[~2009-05-12 11:02 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-12  5:01 Yue Wang
2009-05-12  9:02 ` Yue Wang
2009-05-12  9:09 ` Yue Wang
2009-05-12  9:30   ` Hans Hagen
2009-05-12  9:59     ` Yue Wang
2009-05-12 10:04       ` Yue Wang
2009-05-12 10:06       ` Hans Hagen
     [not found]         ` <4A094C71.3040503@elvenkind.com>
2009-05-12 11:02           ` Hans Hagen [this message]
2009-05-12 11:26             ` Taco Hoekwater
2009-05-12 11:33               ` Yue Wang
2009-05-12 11:52                 ` Taco Hoekwater
2009-05-12 11:57                   ` Hans Hagen
2009-05-12 12:01                   ` Yue Wang
2009-05-12 12:21                     ` Hans Hagen
2009-05-12 12:26                     ` Taco Hoekwater
2009-05-12 12:31                       ` Yue Wang
2009-05-12 11:09           ` Yue Wang
2009-05-12 11:37             ` Hans Hagen
2009-05-12 12:26               ` Yue Wang
2009-05-12 12:54                 ` Hans Hagen
2009-05-12 13:59                   ` Yue Wang
2009-05-12 14:11                     ` Yue Wang
2009-05-12 15:02                       ` Hans Hagen
2009-05-12 15:12                         ` Yue Wang
2009-05-12 15:22                           ` Hans Hagen
2009-05-12 15:45                             ` Yue Wang
2009-05-13  4:38                             ` Yue Wang
2009-05-13  7:49                               ` Yue Wang
2009-05-13  8:28                               ` Hans Hagen
2009-05-12 15:45                           ` Hans Hagen
2009-05-12 14:50                     ` Hans Hagen
2009-05-12 15:10                       ` Yue Wang
2009-05-12 15:14                         ` Taco Hoekwater
2009-05-12 15:41                           ` Hans Hagen
2009-05-12 15:49                             ` Yue Wang
2009-05-12 15:20                         ` Hans Hagen
2009-05-12 15:50                     ` Hans Hagen
2009-05-13  8:59       ` Mojca Miklavec
2009-05-13  9:55         ` Mojca Miklavec
2009-05-13 11:12           ` Hans Hagen
2009-05-13 11:17           ` Hans Hagen
2009-05-13 10:02         ` Wolfgang Schuster
2009-05-13 10:17           ` Mojca Miklavec
2009-05-13 10:41             ` Wolfgang Schuster
2009-05-13 11:12               ` Mojca Miklavec
2009-05-13 11:28                 ` Wolfgang Schuster
2009-05-13 12:48                   ` Thomas A. Schmitz
2009-05-13 12:26                 ` Yue Wang
2009-05-13 12:59                   ` Hans Hagen
2009-05-13 13:25                     ` Wolfgang Schuster
2009-05-12 11:01   ` Wolfgang Schuster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A09574C.6050201@wxs.nl \
    --to=pragma@wxs.nl \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).