<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Merge some optimisation works by Michal Srb?" href="https://bugs.freedesktop.org/show_bug.cgi?id=105102#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Merge some optimisation works by Michal Srb?" href="https://bugs.freedesktop.org/show_bug.cgi?id=105102">bug 105102</a> from <a class="email" href="mailto:jeffbai@aosc.io" title="Mingcong Bai <jeffbai@aosc.io>"> Mingcong Bai</a> <pre>(In reply to Behdad Esfahbod from <a href="show_bug.cgi?id=105102#c7">comment #7</a>) > 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. Not a problem! At present moment, we are narrowing down the rebase area - in similar of your logic to include the most important and significant optimisations. Looking forward to future work on the upstream! On a side note, I tried to generate a .pot file so we could start working on a zh_CN translation for Fontconfig... I ended up with no .pot file at all with the command below... cd po/ && xgettext --files-from=POTFILES.in --directory=.. --output=messages.pot If not, when are you expecting translation works to be ready to start?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>