[Fontconfig-bugs] [Bug 105102] Merge some optimisation works by Michal Srb?

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=105102

--- Comment #7 from Behdad Esfahbod <freedesktop at behdad.org> ---
Here's my take on the optimizations. First a note: KDE's use of FcFontMatch()
with FC_FILE set is bogus and broken. Ignore that.

* 3.4.1 Rewriting FcFontMatch algorithm
-> Valid idea. 10% is worth taking.

* 3.4.2 Value preprocessing
-> Valid concern. It's been on my radar for years. The solution is too invasive
for my taste. Another approach might be to add new pattern elements
FC_FAMILY_HASH, etc, that retain the (corresponding type of) hash of the
string. It will be equally intrusive I'm afraid. But yeah, definitely something
to pursue and see if better implementation is possible. Definitely biggest
waste of time in current FontConfig.  Side note: if we go all the way to keep
hashes of family names, we might end up wanting to use a hashtable for
FcFontMatch...

* 3.4.3 Reducing heap allocations
-> Not clear that is measurable. But sure, is not intrusive. I'm open to.

* 3.4.4 Refactoring FcStrCaseWalkerNext
-> Sounds fine. We might not need to triplicate it, maybe just inline that
function.

* 3.4.5 Micro-optimization in FcCompareValueList
-> I have a hard time believing the 38% speedup claimed. If it has measurable
impact, sounds good to me.

* 3.4.6 Reduce FcObjectFromName call amount
-> Not sure it's worth it; has no measurable impact.

* 3.4.7 Hint branch predictor
-> Good to take, since it's not intrusive. We do these in other libraries.

Anyway, I wish he had done his work in collaboration with us so we could have
discussed and integrated this upstream without pain.  Thanks for bringing up.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fontconfig-bugs/attachments/20180215/9c9eba5a/attachment.html>