Performance report

[behdad]

Three months ago we released 0.1.0 with performance generally 2x to 4x slower than HarfBuzz. Since then @dfrg and I worked to port all the caches and accompanying algorithms from HarfBuzz to HarfRust, as well as micro-optimizations.

The result is that in benchmarks for both OpenType and AAT we are withing 25% speed of HarfBuzz now:

https://docs.google.com/spreadsheets/d/1lyPPZHXIF8gE0Tpx7_IscwhwaZa4KOpdt7vnV0jQT9o/preview

Note that HarfBuzz itself has significantly been sped up over the past three years, making it really hard to outperform it:

https://docs.google.com/spreadsheets/d/1_sxJS6zmdpI_sNz5aUdsjThk40OB1Twjvqh4UORJWQg/preview

[behdad]

I looked into what's remaining between HR and HB performance. For once, Fontations parsing and read model, versus HarfBuzz's sanitize & unchecked-access model, has some overhead. What the caches do is that we read GSUB/GPOS data a lot less than a naive implementation. As such, the more complex the font is, the more performance gap will appear between the two implementations.

I looked into Roboto-Regular performance, which is highly optimized in HB. The spreadsheet shows it at 1.12x HB time. About 0.015 of that goes away if I make the Unicode tables unsafe unchecked access. I don't advise that we take this though if that's gonna be the only unsafe we take. However, upon further investigation, about 6% is spent in hb-harfrust conversion from HB buffer to HR buffer and converting (and scaling) back the results (symbol _hb_harfrust_shape_rs). So. We're actually closer to 1.06x HB for Roboto.

Currently HB time on Roboto benchmark is 6.54ms vs HR 7.34ms. If I strip Roboto of GDEF/GSUB/GPOS, called Roboto-Potato, then HB time is 1.24ms vs HR 1.67ms. We can associate most of the difference, say, 0.4ms to hb-harfrust overhead. Subtracting the overhead from Roboto times gets HR down to 6.94ms vs HB's 6.54ms, resulting in 1.06% confirming the number in the previous paragraph as well.