Fix HVAR/VVAR performance regression from eager metric computation#1708
Conversation
|
fontc v0.3.2 still ran 1.58 ± 0.05 times faster (10s vs 16s) than fontc built from this PR according to hyperfine, but before this it was like 7x faster on my machine |
The VVAR refactoring pre-computed GlobalMetricsInstance for all locations upfront, causing thousands of unnecessary interpolations for sparse fonts. HVAR doesn't need metrics at all (only width), and VVAR was recomputing the same location's metrics once per glyph. We now compute metrics on-demand for VVAR only and cache per unique location. Fixes #1706
577e1d0 to
cdb3beb
Compare
|
for testing, I have also branched off the bisected commit and cherry-picked this PR's commit on top (only fixing a few conflicts) -- I pushed it here if you want to check: https://github.com/googlefonts/fontc/compare/perf-test-isolated When I run hyperfine off of that branch and compare with v0.3.2 (from wheel), I get basically the same time. So while there may be other things that we added later on main that we could optimize, this fixes the major one so it's good to merge. |
|
Will reiterate that it will be nice to set up some ongoing performance tracking at some point, would be great to catch this sort of thing in CI. |
The VVAR implementation in #1666 pre-computed GlobalMetricsInstance for all glyph locations upfront, causing thousands of unnecessary interpolations for sparse fonts. HVAR doesn't need metrics at all (only width), and VVAR was even recomputing the same location's metrics once per glyph, instead of once per unique glyph location.
We now compute metrics on-demand for VVAR only and cache per unique location.
Fixes #1706