benchmarking rust subsetting against hb-subset

[cmyr]

As of late this week I have codegen working for all of the compilation types in GPOS, and I'm ready to start thinking about the 'demonstration subsetter' discussed in #20.

Basically: we want to choose some task that is representative of the work of subsetting, but which will involve a modest subset of the work involved in a full implementation.

My current plan is to focus on only subsetting the GPOS table, and then comparing the output and the runtime to what is produced by HarfBuzz.

I think it might make sense to schedule a quick call and talk about this? I have various questions about things like constructing the subset plan, and how we might reduce scope, but it would be helpful to have input from someone with more knowledge of the HarfBuzz subsetter.

In any case I'm going to spend next week working on porting the repacker, since that's something we're going to need regardless.

[rsheeter]

For non-work reasons I'm out until July 12. I think @garretrieger could help pick some representative subsetting scenarios, and comment on whether GPOS only is sufficient or if we really need GSUB for an interesting comparison.

As of late this week I have codegen working for all of the compilation types in GPOS

Awesome, when I'm back I want you to walk me/us through how to use all the new toys (bearing in mind some of us don't yet speak Rust)

[cmyr]

Sounds good, I'll reach out to garret to talk through some of the details, and we can catch up in July.

[garretrieger]

Yes, happy to chat about this. Some initial thoughts:

• GPOS and GSUB are basically equivalent for subsetting except for the glyph closure operation which applies only to GSUB.
• So if you don't initially implement glyph closure then I would start with benchmarking GPOS, but you'll definitely want to benchmark GSUB as well once you have closure support. For complex fonts closure can be a significant portion of the overall subsetting time.
• For initial benchmarks, I would start with one of the simpler and commonly used lookup types. For most fonts these are where the bulk of subsetting time is spent. For example I think I good starting test case would be a GPOS table with a large number of PairPos lookups. This should be a good test if your fundamentals are in good shape (ie. serialization, coverage table intersection, and lookup/feature/script indices collection).
• If you initially keep the GPOS/GSUB table size below 64kb then you won't have to deal with repacking either, which is fine for initial benchmarks. Like closure though you will eventually want to have benchmarks covering repacking as it can be pretty expensive.

[garretrieger]

FYI here's the set of fonts we currently include in the hb benchmark suite: https://github.com/harfbuzz/harfbuzz/blob/main/perf/benchmark-subset.cc#L22

These were picked to cover several interesting subsetting scenarios (eg. complex GSUB/GPOS, large character counts, simple GSUB/GPOS, CFF vs glyf)