[cairo] Performance degradation of font cache in 1.11.3

[Andrea Canciani]

On Fri, Dec 30, 2011 at 10:53 AM, Deokjin Kim <deokjin81.kim at samsung.com> wrote:
> Hello all,
>
> When I measure elapased time of cairo using cairo-perf-trace, elapsed time of 1.10.2(release version) is shorter than that of 1.11.3(latest code). That is, performance of 1.10.2 is better than that of 1.11.3.
> I think change of font cache is playing a role in causing this issue.
>
> I found two root cause.
> 1. Use original_font_face instead of font_face when you create key of scaled font in cairo_scaled_font_create().
>  This change degrades hit ratio of _cairo_hash_table_lookup().
>
>  Below is related source code of 1.11.3.
>  1028         _cairo_scaled_font_init_key (&key, original_font_face,
>  1029                                      font_matrix, ctm, options);  // In 1.10.2, use font_face instead of original_font_face

This change happened in commit cd4b2d843b2a8c06ba78c15ff65763b5bdf54dc6
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Wed Jul 13 12:33:48 2011 +0100

    scaled-font: Key the cache on the orignal font_face

    We check the incoming scaled font using the original font fce, so we
    need to also store it in the cache using the same face, and not the
    resolved font_face (which will remain the same unless the fontconfig
    configuration is updated).

    Hides the quadratic behaviour of font retrieval in recent cairo-traces.

    Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>

AFAICT (based on the commit message) the performance of cairo-traces
should improve with it.



>  1030
>  1031         while ((scaled_font = _cairo_hash_table_lookup (font_map->hash_table,
>
> 2. Some change of hash table.
>  - hash: Improve double hashing
>  - hash: Compare hash values before calling keys_equal
>  - hash: Improve handling of dead entries
>  I think purpose of above code change is very good, but actual result is not good.

The performance in most practical cases should be unaffected by these changes.
In some cases (if the hash table almost fills up with dead entries) it
should be way better, as shown by the hash-table micro benchmark.

In fact I would expect the first two commits ("hash: Improve double
hashing", "hash: Compare hash values before calling keys_equal") to
have a performance impact which is basically hidden by noise.
The third commit might make the performance somewhat worse in some
cases, but it guarantees that it cannot degenerate into something
really terrible.

(It is very useful to also have the refid of commits. The above
commits are uniquely identified by
02665975d3ef0204bc512de1be55f898637f2d21 hash: Improve double hashing
400d055f3cd2eecd2cc4b91a40eac4146ec61932 hash: Compare hash values
before calling keys_equal
aaa10fbf125a80e5379172b8564384a945728cba hash: Improve handling of dead entries
)

>
> As I know, 1 is more significant than 2.
> (Actually influence of 2 is slight.)
>
> Please give me advice.

Could you provide some additional details about what benchmark you are
running? (what traces, backends...)

Also, could you try and give performance numbers about:
 - cairo 1.10.2 (release version)
 - cairo 1.10.2 (release version) + "1"
 - cairo 1.10.2 (release version) + "1" + "2"

 - cairo master (6816f70da54e730e88b98c8592aa6fc84e082928)
 - cairo master (6816f70da54e730e88b98c8592aa6fc84e082928) + revert "1"
 - cairo master (6816f70da54e730e88b98c8592aa6fc84e082928) + revert
"1" and revert "2"

This would be very useful in figuring out if (and how much) these
commits affect performance.

It should also be pointed out that there have been major changes in
the compositing architecture between 1.10 and current master, which
are likely to have a much bigger performance impact.

> Thank you in advance.

Thank you for benchmarking cairo :)

Andrea

>
> BR,
> Deokjin Kim
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo