Cache repeated subtables while building COLR #3215
Conversation
|
...but this only works when you're sending a plain JSON-style object to |
|
hm yeah, the API supports a mix of raw dicts and prebuilt subtables and I'd like to keep that way. Also I'm a bit meh on having KBs of JSON for the cache dict keys.. |
simoncozens
force-pushed
the
cache-colr-builds
branch
from
98c3a29
to
32dff74
Compare
|
I'm worried about the potential risk of collisions when using hash instead of the strings themselves as the key. This SO suggests using more cryptographically robust hashlib (also in stdlib). EDIT: forgot to paste the link: https://stackoverflow.com/a/68048420 |
|
also how about we make this caching optional by adding a parameter to the buildCOLR table that trickles down to the TableBuilder constructor? Maybe for your particular use case this may make things faster, but for the general case I am not sure whether the cost of pickling and caching outweighs the benefits |
|
Closing in favour of #3221 |
my PR was based off yours, the idea was if you liked that suggestion you could merge that first into your PR branch and proceed from there. But since you closed this one I have rebased my PR onto main. Feel free to pick that one up |
When building a complex COLR table, particularly for a font with a large number of glyphs, there can be many repeated subtables. Instead of rebuilding each subtable from scratch, a simple cache can be used to speed up the build.
For example, building Bitcount without the cache takes 274 seconds on my computer; with the cache, it takes 94.