Hi all, we have had a look at our performance with Fontconfig 2.2.96 and have some questions: 1) there seems to be a huge number of strcmp operations when handling the fonts. In my test run I got over a million of such comparisons originated form Fontconfig! Element names are compared again and again. Do we feel this should be optimized? Does anyone work on that already? 2) The usage of floating point types. Those matching results are "double" even though majority of comparisons do not return any real floating point value. Not a problem on x86 but when run on ARM this becomes really bad really fast. Should we think about optimizations here too? Anyone working on that already? Br, --jakub
On Tue, 2004-10-12 at 12:18 +0300, Jakub Pavelek wrote:> Hi all, > > we have had a look at our performance with Fontconfig 2.2.96 and have > some questions: > > 1) there seems to be a huge number of strcmp operations when handling > the fonts. In my test run I got over a million of such comparisons > originated form Fontconfig! Element names are compared again and again. > Do we feel this should be optimized? Does anyone work on that already?What kind of operations are using? Even better, could you create a small benchmark that simulates what your program is doing? 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 don''t really know of any work being done. For desktop performance memory usage and startup time is definitely people''s main concern with fontconfig at the moment. That''s partly because common toolkits (Pango and I think also Qt) have higher levels of caching above fontconfig.> 2) The usage of floating point types. Those matching results are > "double" even though majority of comparisons do not return any real > floating point value. Not a problem on x86 but when run on ARM this > becomes really bad really fast. > Should we think about optimizations here too? Anyone working on that > already?I haven''t heard of anybody working on that. 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. Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041012/16d44c7a/attachment.pgp
On Tuesday 12 October 2004 23:34, Keith Packard wrote:> 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.For Qt we tried to model our font loader after the CSS model. If this would help fontconfig as well, I''m all for it.> And, using some kind of canonical string set and pointer compares would > eliminate all calls to strcmp past the API.I was always wondering why the API uses strings for the identifiers at all. Wouldn''t an enum as enum FcIdentifiers { FC_FAMILY,?FC_SLANT, FC_WEIGHT, ... } fit the purpose as well, be typesafe and get rid of all string compares (and lots of defines in the header). I know this is difficult now, as it would break compatibility, but maybe for the future.> > That''s partly because common toolkits (Pango and I think also Qt) have > > higher levels of caching above fontconfig.We need to do this currently. In some fallback cases we go through fontconfig directly to find a font to use, and this path is rather slow (esp. if you have a large number of fonts installed).> 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).Possible, but we would still need to do some sort of caching of loaded fonts, as that is outside of the scope of fontconfig. Currently we still have some problems finding the right font needed to render e.g. a certain writing system through fontconfig. Esp. if we require open type tables (e.g. for arabic or indic languages), fontconfig doesn''t always give the right answer. Cheers, Lars
On Tue, 2004-10-12 at 14:34 -0700, Keith Packard wrote:> 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.Well, that''s certainly how Pango works - pango_font_family_list_faces(), pango_font_face_list_sizes(). An internal organization on this would help FcFontMatch a lot, but as far as I can see, isn''t going to be any use for FcFontSort.> 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).The big thing that needs to be cached in Pango is actually FcFontSort() results ... there are some performance problems with the Pango font iteration APIs currently due to the slowness of FcFontMatch() but that''s really peripheral. I''m not sure how to get around caching FcFontSort results - it''s pretty much inherently a slow operation. What would help a *lot* in reducing the size of that cache would be to finesse BDF/PCF fonts in some way and make the FcFontSort results independent of pixel size. Not that I have any good idea for how to do that. Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041013/88a614fe/attachment.pgp
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://lists.freedesktop.org/archives/fontconfig/attachments/20041012/58a4f922/attachment.pgp
Around 8 o''clock on Oct 13, Owen Taylor wrote:> An internal organization on this would > help FcFontMatch a lot, but as far as I can see, isn''t going to be > any use for FcFontSort.We can pull up Unicode information to the internal tree nodes and trim large swaths of the search space that way.> The big thing that needs to be cached in Pango is actually FcFontSort() > results ... there are some performance problems with the Pango font > iteration APIs currently due to the slowness of FcFontMatch() but that''s > really peripheral.It might be reasonable to push that down into Fontconfig if we find other applications doing the same thing.> What would help a *lot* in reducing the size of that cache would be to > finesse BDF/PCF fonts in some way and make the FcFontSort results > independent of pixel size. Not that I have any good idea for how to do > that.That''s easy -- migrate the BDF/PCF fonts to TTF files which include all of the sizes in a single file. That will dramatically reduce the number of entries in the database. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041013/eeff60be/attachment.pgp
Around 12 o''clock on Oct 13, Owen Taylor wrote:> Well, if we *eliminate* BDF/PCF font support, that helps. Otherwise, > I don''t see it helping much.Now I''m confused -- I thought the time was consumed by wandering through miles of bitmap fonts. Eliminating essentially all of the bitmap fonts seems like a good way to make that faster... -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041013/033d8178/attachment.pgp
Around 13 o''clock on Oct 13, Owen Taylor wrote:> What I''m talking about is that FcFontSort() results potentially depend > upon the pixel size. This makes caching both much more expensive and > much less effective. Depending *less* on pixel size doesn''t help with > that.Hmm. It might be useful to know when the FcFontSort isn''t dependent on the font size; I think that will be true a lot of the time. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041013/06736ff7/attachment.pgp
On Wed, 2004-10-13 at 09:35 -0700, Keith Packard wrote:> > What would help a *lot* in reducing the size of that cache would be to > > finesse BDF/PCF fonts in some way and make the FcFontSort results > > independent of pixel size. Not that I have any good idea for how to do > > that. > > That''s easy -- migrate the BDF/PCF fonts to TTF files which include all of > the sizes in a single file. That will dramatically reduce the number of > entries in the database.Well, if we *eliminate* BDF/PCF font support, that helps. Otherwise, I don''t see it helping much. Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041013/343beae0/attachment.pgp
Keith Packard <keithp@keithp.com> writes:> Now I''m confused -- I thought the time was consumed by wandering through > miles of bitmap fonts. Eliminating essentially all of the bitmap fonts > seems like a good way to make that faster...What about those of us who want to use bitmap fonts in applications that insist on getting fonts from fontconfig? :) Kyle
On Wed, 2004-10-13 at 10:02 -0700, Keith Packard wrote:> Around 12 o''clock on Oct 13, Owen Taylor wrote: > > > Well, if we *eliminate* BDF/PCF font support, that helps. Otherwise, > > I don''t see it helping much. > > Now I''m confused -- I thought the time was consumed by wandering through > miles of bitmap fonts. Eliminating essentially all of the bitmap fonts > seems like a good way to make that faster...What I''m talking about is that FcFontSort() results potentially depend upon the pixel size. This makes caching both much more expensive and much less effective. Depending *less* on pixel size doesn''t help with that. Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041013/a73597b8/attachment.pgp