Skip to content

Cache all fields from PairPos2 and avoid reading subtable#260

Open
dfrg wants to merge 1 commit into
mainfrom
opt-pairpos2
Open

Cache all fields from PairPos2 and avoid reading subtable#260
dfrg wants to merge 1 commit into
mainfrom
opt-pairpos2

Conversation

@dfrg

@dfrg dfrg commented Sep 10, 2025

Copy link
Copy Markdown
Collaborator

Attempt at #256

@dfrg
dfrg requested a review from behdad September 10, 2025 22:50
@dfrg

dfrg commented Sep 10, 2025

Copy link
Copy Markdown
Collaborator Author

@valadaptive this avoids subtable reparsing entirely for pairpos2. Would you mind checking if this improves your profile?

@valadaptive

Copy link
Copy Markdown
Contributor

Yes! This speeds up shaping Ubuntu Light by ~8% in the benchmark.

@behdad

behdad commented Sep 11, 2025

Copy link
Copy Markdown
Member

Looks good in general. Should we remove the unused impl then?

Any way to make this more harmonious across lookup types would be nice. Would it be too heavy to do this kind of caching on every lookups?

@dfrg

dfrg commented Sep 11, 2025

Copy link
Copy Markdown
Collaborator Author

Yes to all. This needs a bit of cleanup before merging, the code should be better structured to accommodate it and we should try to do this for all lookups.

dfrg added a commit that referenced this pull request Jan 5, 2026
This extracts the primary coverage table (along with any suitable caches) into a field on `SubtableInfo` so that we can check coverage before attempting to parse the subtable. The glyph id, coverage index, coverage metadata and external cache are then passed to the subtable apply function in a new `ApplyState` parameter. This avoids some buffer indexing and reparsing the primary coverage table.

This attempts to clean up and unify some of the caching code paths along with laying some groundwork for future optimizations (like #260).

HR benchmarks seem to show a reasonable gain on non-Latin shaping as a bonus.
@behdad

behdad commented Jul 3, 2026

Copy link
Copy Markdown
Member

Do we still need this? Is it already done? Would the faster read-fonts obviate this?

@dfrg

dfrg commented Jul 4, 2026

Copy link
Copy Markdown
Collaborator Author

I think this one might still be useful but we’ll need to rebase and measure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants