<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Make fontconfig scanning faster" href="https://bugs.freedesktop.org/show_bug.cgi?id=64766#c24">Comment # 24</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Make fontconfig scanning faster" href="https://bugs.freedesktop.org/show_bug.cgi?id=64766">bug 64766</a> from <a class="email" href="mailto:freedesktop@behdad.org" title="Behdad Esfahbod <freedesktop@behdad.org>"> Behdad Esfahbod</a> <pre>Ok, I looked into this a bit. First, I made some cleanups to the FC_HASH code. It's as streamlined as it can be right now. That said: * We spend more than half of the time in computing the hash, * Of the remaining time, we spend half verifying that each glyph has an outline, The rest I suppose we spend computing the languages covered by the font... So. I think we might want to: * Reconsider the FC_HASH. I could see a use for FC_HASH for speeding up cache rebuild, but given that querying the rest of the font is faster than computing the hash, it makes no sense. So we're left with a FC_HASH that some clients might find useful, but so far we don't have anyone actually using it. So we might as well remove it. * Alternatively, keep FC_HASH, but not compute it if file=NULL is passed to FcFreeTypeQueryFace. Previously, file=NULL was NOT supported and one had to pass file="" or something like that. I just made file="NULL happily not add FC_FILE. I think we can use the same as a signal to skip FC_HASH calculation. That helps with the "make querying memory fonts faster" at least, but not quite with the cache generation speed, * If font has loca/glyf tables, access those directly instead of loading glyphs from FreeType, * See where the rest of the time is going and speed that up. What do people think about FC_HASH? Should we just remove it?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>