In the mean time, I think we should switch hb-shape / hb-view to cache their own plan. On Oct 29, 2013 10:10 PM, "Jonathan Kew" <[email protected]> wrote:
> Hey Behdad, > > I figured out why the dashboard figures make it look as though we're > surprisingly slow when running the XP fonts with simple scripts (e.g. > Latin, Cyrillic). > > The problem is that my test framework passes "--features kern=0" for these > tests in order to suppress use of the legacy 'kern' table, so that we'll > better match Uniscribe's shaping results. But (somewhat surprisingly, at > first glance) running with kern=0 is substantially *slower* than running > without it: > > $ time hb-shape arial-winxp.ttf --text-file ru.txt > /dev/null > real 0m38.831s > user 0m38.726s > sys 0m0.106s > > $ time hb-shape arial-winxp.ttf --text-file ru.txt --features kern=0 > > /dev/null > real 0m50.087s > user 0m49.984s > sys 0m0.104s > > Explicitly specifying kern=1 is slower still, although the shaped results > will be identical to the no-user-feature case: > > $ time hb-shape arial-winxp.ttf --text-file ru.txt --features kern=1 > > /dev/null > real 0m56.122s > user 0m56.022s > sys 0m0.101s > > The reason for this, as you no doubt realized right away, is that passing > *any* user features will prevent hb_shape() taking advantage of a cached > shape plan in the font, and so we re-create the plan for every string. This > is pretty expensive, and results in the slowdown here. > > Caching plans with arbitrary user features may be a bit tricky, but what I > suggest we could do to address this for the common use case is to cache > plans with user features *provided* all the user features are "global" > (i.e. they have start=0, end=-1). And only use a cached plan if the list of > features is exactly the same - i.e. the same tags and values (and global > ranges) and listed in the same order. Make no attempt to decide whether > different feature lists could in fact share the same plan, just refuse to > use a cached plan if there's *any* difference. This makes it reasonably > easy and cheap to do the caching, and in practice it's still likely to hit > the vast majority of the use cases. > > The attached patch implements this, and with this applied, I now see > kern=0 resulting in a substantial speed-up, as expected, instead of a > slow-down compared to the default shaping: > > $ time hb-shape arial-winxp.ttf --text-file ru.txt --features kern=0 > > /dev/null > real 0m30.807s > user 0m30.722s > sys 0m0.086s > > And explicitly setting kern=1 shows no significant difference from the > original no-features case (the variation from the first run above is within > the noise level): > > $ time hb-shape arial-winxp.ttf --text-file ru.txt --features kern=1 > > /dev/null > real 0m37.544s > user 0m37.453s > sys 0m0.091s > > So I'd suggest it's worth doing something like this - unless of course you > want to go the whole way and implement "smart" plan caching with user > features, but IMO that sounds like it might be more effort than it's worth. > > JK > >
_______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
