Draft: Making test_cell_speed_with_long_text() faster

[Lucas-C]

This is a follow-up to #911

I made minor performance-oriented improvements to SubsetMap:

• in 2 places, use a single call to dict.get(key) instead of key in dict + dict[key]
• define our own, fast, __hash__() method
• add a cache (._char_id_per_unicode) to avoid repeated processings in SubsetMap.pick()

I also used this opportunity to remove all accesses to the private property ._map
from outside the SubsetMap class.

cf. #907 for some context

[codecov-commenter]

Codecov Report

Patch coverage: 89.65% and project coverage change: +0.09% 🎉

Comparison is base (6e3334f) 93.23% compared to head (4a27a86) 93.32%.

❗ Current head 4a27a86 differs from pull request most recent head 54dac02. Consider uploading reports for the commit 54dac02 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #913      +/-   ##
==========================================
+ Coverage   93.23%   93.32%   +0.09%     
==========================================
  Files          27       27              
  Lines        7684     7686       +2     
  Branches     1395     1393       -2     
==========================================
+ Hits         7164     7173       +9     
+ Misses        330      322       -8     
- Partials      190      191       +1     

Files Changed	Coverage Δ
fpdf/fonts.py	95.33% <88.88%> (+3.03%)	⬆️
fpdf/output.py	97.18% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Lucas-C]

@andersonhc & @gmischler: do you want to review this before I merge it? 🙂
Any other suggestions to make this code faster?

[gmischler]

These changes all look fine to me.
Given how you reduced the expected test time from 23 to 18 seconds, they seem to result in a roughly 20% speed up. It will be interesting to see how the flame graph changes with that to find further bottlenecks.

[andersonhc]

Mapping directly unicode to glyph ID should give a performance similar to 2.7.4 and the way you implemented it doesn't impact shaping. I don't have any improvement to suggest at this point.

[Lucas-C]

Thank you for your feedbacks!

Merged 🙂

[Lucas-C]

Given how you reduced the expected test time from 23 to 18 seconds, they seem to result in a roughly 20% speed up. It will be interesting to see how the flame graph changes with that to find further bottlenecks.

Sadly, this is in fact really not a stable metric:
https://github.com/py-pdf/fpdf2/actions/runs/6097064580/job/16543945606
😞

I fear that our pipelines "speed" / available CPU depend too much on the current load on the GitHub Actions system...