[HarfBuzz] caching plans with user features

[Jonathan Kew]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cache-shape-plan-with-features.patch
Type: text/x-patch
Size: 5490 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20131029/d51c0a6e/attachment.bin>