[cairo] text measurement in perf?

[Baz]

On 30/05/07, JustFillBug <mozbugbox at yahoo.com.au> wrote:
> On 2007-05-29, Behdad Esfahbod <behdad at behdad.org> wrote:
> >
> > Seems like for both Chinese and Japanese a cache of around 2000
> > character is more than enough (same way that 256 is more than enough for
> > Western scripts).  Not sure how to fix this without regressing.  Xft has
> > a global cache size limit and a per-font one, and uses a global glyph
> > cache.  Cairo used to be similar but Keith rewrote it to use per-font
> > glyph cache.  We probably should make it adaptive.  I need to do similar
> > things in Pango too, so I'll give it some thought and come back.
> >
>
> 2 stage cache. 1st 256, 2nd 2048.
>

There's some micro-optimisations that could be made to the hashtable
code too, which'll make more of a difference if it gets larger.

In _cairo_hash_table_lookup_internal, key_is_unique is tested inside
the loop but never changes; step is tested and changed inside the loop
but can be initialized outside the loop instead. So we can tighten the
loop a bit:

    step = key->hash % hash_table->arrangement->rehash;
    if (step == 0)
        step = 1;

    if (key_is_unique) {
        // loop
    } else {
        // loop
    }

... this should cut 571 * 2 comparisons or so on a cache miss,
currently, and would cut 9000ish comparisons on a miss with the larger
cache.

However, the biggest cost is going to be the calls to
hash_table->keys_equal(key, *entry), which for this particular cache
boils down to an equality test. Could we do better here? A hacky
suggestion - if hash_table->keys_equal is null, do the loop with a
hash equality test instead, getting rid of the function call overhead.

I haven't timed any of this yet, just thinking about it while stuck at
work, but I remember those calls being high on the profiles in my
tests.

As Behdad says, this might not make a difference in real world
scenarios; if we're getting lots of cache misses the cache isn't
working right anyway.

-Baz