Around 17 o'clock on Oct 12, Owen Taylor wrote: > There are certainly some things that are known slow - the fact that > all FcFontMatch operations involve a linear scan could be improved > by adding some hash table indices. (There's a bug in bugzilla about > that.) But I'm a little surprised of 1 million + strcmps if you > are working with a small number of fonts. I'm actually wondering how well we could do if we were closer to the CSS font matching spec; that might permit a heirarchical database split across family/style/size boundaries which could reduce the search space for a particular pattern. Converting the unsorted search to one which can use a sorted (or hashed) set of family names should make things a lot faster. And, using some kind of canonical string set and pointer compares would eliminate all calls to strcmp past the API. > That's partly because common toolkits (Pango and I think also Qt) have > higher levels of caching above fontconfig. Which would be nice to eliminate somehow; duplicating the font data in yet another format is not helping performance here. Not that the current fontconfig format is useful for Pango, but perhaps we could design something as a replacement for all three systems (Pango, Qt and fontconfig). > It's probably possible to replace the doubles with strcol-style sort > keys or similar, though it will certainly not help performance where > doubles *are available. A large portion of the 'double' work done today is actually on integers converted on-the-fly to doubles; it's easier to always convert to the most general format, do the operation and then convert back than to try and figure out when you can do the whole operation in integers. That should be fixable if someone has an interest. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://freedesktop.org/pipermail/fontconfig/attachments/20041012/58a4f922/attachment.pgp
