Hi all, The folks at SuSE have been profiling and contributing a number of performance patches for fontconfig, which I''ve all reviewed and committed. The most recent one is for FcFontSetMatch, which they report gives a 3.5x speedup in fontconfig; that patch rewrote the algorithm by inlining FcCompare and swapping the order of the loops, blocking fonts that were ineligible for being the best font. So while both the old algorithm and the new algorithm are linear in the number of installed fonts, the new algorithm is much faster than the old algorithm by doing a lot less value list compares. Lots of thanks to Dirk Mueller, Stephen Kulow and Michael Matz! pat
On Sun, 2005-11-27 at 20:48 -0500, Patrick Lam wrote:> Hi all, > > The folks at SuSE have been profiling and contributing a number of > performance patches for fontconfig, which I''ve all reviewed and > committed. The most recent one is for FcFontSetMatch, which they report > gives a 3.5x speedup in fontconfig; that patch rewrote the algorithm by > inlining FcCompare and swapping the order of the loops, blocking fonts > that were ineligible for being the best font.I think most applications should use FcFontSetList instead so that they receive the set of fonts necessary to render arbitrary characters, instead of a single font with limited Unicode coverage. I know that Pango and Mozilla both use the listing function exclusively; I''m not sure how to improve the performance of this function though. -keith -------------- 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/20051127/4f99b2fd/attachment.pgp
Am Montag, 28. November 2005 05:04 schrieb Keith Packard:> > I think most applications should use FcFontSetList instead so that they > receive the set of fonts necessary to render arbitrary characters, > instead of a single font with limited Unicode coverage. I know that > Pango and Mozilla both use the listing function exclusively; I''m not > sure how to improve the performance of this function though.Unfortunately this is not true, firefox spends roughly 49% of the time it takes to call "firefox-bin http://www.fontconfig.org" in 9 FcFontSort calls (if you have enough fonts installed). The FcFontSetList function you name is called by Qt though and is also horribly expensive as it rebuilds the full list of FcPatterns according to the FcObjectSet given using hashes to group the list. For the Qt case it''s enough if FcFontList had a way to get _all_ fonts. We toyed around with providing a 0 pointer to FcFontList and this kind of works, but as the API will be backwards compatible, but crash when the old library is called from new applications, it would be better if the APIs were different there. Any suggestions? I see different ways like a FcCreateAnyObjectSet() or the suggested 0 pointer - or changing the semantic of the empty ObjectSet (which had the advantage of being able to write fontconfig version agnostic application code: "if FcFontSetList(FcCreateObjectSet())->nfonts == 0: FcFontSetList(theRealOS)" But yes, FcFontSort needs some major optimizing - and you will only gain small parts if you adopt techniques we used for optimizing FcFontMatch. But then again: I think if you throw away fonts early as they share scripts already provided by the merged set, you could gain some more. But this indeed needs more thinking. But I learned my lesson: I''ll deinstall most of the fonts I installed for testing, 1.3 Billion instructions in firefox''s FcFontSortfirefox teached me :) Greetings, Stephan
On Sun, 2005-11-27 at 20:48 -0500, Patrick Lam wrote:> Hi all, > > The folks at SuSE have been profiling and contributing a number of > performance patches for fontconfig, which I''ve all reviewed and > committed. The most recent one is for FcFontSetMatch, which they report > gives a 3.5x speedup in fontconfig; that patch rewrote the algorithm by > inlining FcCompare and swapping the order of the loops, blocking fonts > that were ineligible for being the best font. So while both the old > algorithm and the new algorithm are linear in the number of installed > fonts, the new algorithm is much faster than the old algorithm by doing > a lot less value list compares. > > Lots of thanks to Dirk Mueller, Stephen Kulow and Michael Matz! > > patHmm, I might be missing something, but after updating today, my fc-list does not list any fonts anymore. Maybe the optimization was a bit too drastic... Matthias
Matthias Clasen wrote:> Hmm, I might be missing something, but after updating today, my fc-list > does not list any fonts anymore. Maybe the optimization was a bit too > drastic...Yeah, there was a problem with the first patch. It''s fixed now though. pat
On Mon, 2005-11-28 at 23:19 -0500, Patrick Lam wrote:> Matthias Clasen wrote: > > > Hmm, I might be missing something, but after updating today, my fc-list > > does not list any fonts anymore. Maybe the optimization was a bit too > > drastic... > > Yeah, there was a problem with the first patch. It''s fixed now though.If you are referring to 2005-11-28 Patrick Lam <plam@mit.edu> * src/fcint.h: * src/fcpat.c (FcPatternFindFullFname): * src/fccfg.c (FcConfigBuildFonts): Fix problem dating back at least to 2.3.2 where globs weren''t being applied to patterns loaded from a cache. my cvs snapshot has that change, and the following one, and still doesn''t list any of the fonts which the snapshot from 20051119 found... Matthias
Matthias Clasen wrote:> On Mon, 2005-11-28 at 23:19 -0500, Patrick Lam wrote: > >>Matthias Clasen wrote: >> >> >>>Hmm, I might be missing something, but after updating today, my fc-list >>>does not list any fonts anymore. Maybe the optimization was a bit too >>>drastic... >> >>Yeah, there was a problem with the first patch. It''s fixed now though. > > > If you are referring to > > 2005-11-28 Patrick Lam <plam@mit.edu> > * src/fcint.h: > * src/fcpat.c (FcPatternFindFullFname): > * src/fccfg.c (FcConfigBuildFonts): > > Fix problem dating back at least to 2.3.2 where globs weren''t > being applied to patterns loaded from a cache. > > > my cvs snapshot has that change, and the following one, and still > doesn''t list any of the fonts which the snapshot from 20051119 found...Hmm, no, 2005-11-28 ''Don''t kill all fonts during match (oops!)'' should have fixed that. fc-list still lists fonts for me. But was it perhaps the change in globs? There''s still something wrong with that which I''m going to investigate this evening. pat
On Mon, 2005-11-28 at 23:39 -0500, Patrick Lam wrote:> Matthias Clasen wrote: > > On Mon, 2005-11-28 at 23:19 -0500, Patrick Lam wrote: > > > >>Matthias Clasen wrote: > >> > >> > >>>Hmm, I might be missing something, but after updating today, my fc-list > >>>does not list any fonts anymore. Maybe the optimization was a bit too > >>>drastic... > >> > >>Yeah, there was a problem with the first patch. It''s fixed now though. > > > > > > If you are referring to > > > > 2005-11-28 Patrick Lam <plam@mit.edu> > > * src/fcint.h: > > * src/fcpat.c (FcPatternFindFullFname): > > * src/fccfg.c (FcConfigBuildFonts): > > > > Fix problem dating back at least to 2.3.2 where globs weren''t > > being applied to patterns loaded from a cache. > > > > > > my cvs snapshot has that change, and the following one, and still > > doesn''t list any of the fonts which the snapshot from 20051119 found... > > Hmm, no, 2005-11-28 ''Don''t kill all fonts during match (oops!)'' should > have fixed that. fc-list still lists fonts for me. But was it perhaps > the change in globs? There''s still something wrong with that which I''m > going to investigate this evening.The globs change clearly has a big effect. The results of fc-list | wc -l on my system are as follows: cvs20051119: 143 before globs change: 148 current cvs: 0 Matthias
Matthias Clasen wrote:> The globs change clearly has a big effect. The results of > fc-list | wc -l on my system are as follows: > > cvs20051119: 143 > before globs change: 148 > current cvs: 0Hmm, there shouldn''t be a difference between before globs change and cvs20051119. However, 0 is a number I''m not reproducing. Can you check your config and try rebuilding your caches? pat
On Tue, 2005-11-29 at 00:19 -0500, Patrick Lam wrote:> Matthias Clasen wrote: > > The globs change clearly has a big effect. The results of > > fc-list | wc -l on my system are as follows: > > > > cvs20051119: 143 > > before globs change: 148 > > current cvs: 0 > > Hmm, there shouldn''t be a difference between before globs change and > cvs20051119. However, 0 is a number I''m not reproducing. Can you check > your config and try rebuilding your caches?I just rebuilt my caches with fc-cache from current cvs, and fc-cat lists the contents of the cache files as expected. Still, fc-list comes up empty. Matthias
Matthias Clasen wrote:> On Tue, 2005-11-29 at 00:19 -0500, Patrick Lam wrote: > >>Matthias Clasen wrote: >> >>>The globs change clearly has a big effect. The results of >>>fc-list | wc -l on my system are as follows: >>> >>>cvs20051119: 143 >>>before globs change: 148 >>>current cvs: 0 >> >>Hmm, there shouldn''t be a difference between before globs change and >>cvs20051119. However, 0 is a number I''m not reproducing. Can you check >>your config and try rebuilding your caches? > > I just rebuilt my caches with fc-cache from current cvs, and fc-cat > lists the contents of the cache files as expected. Still, fc-list comes > up empty.For no good reason I had at one point 0 fonts as well. However, I''ve updated current CVS with a couple of changes, using a more stable API to get the font filenames. Unfortunately, this is going to hurt the perf of FcInit. Anyway, I think that the code is now actually correct, and seems to work fine for me at least. Rebuilding caches doesn''t seem to help, but recompiling everything might help. Globs now check both the full filename and the pathname to see whether or not they belong to a rejection glob. This can actually be greatly sped up, come to think of it. The per-directory rejection glob only needs to be done once per cache directory. Unfortunately, the full filename still has to be checked; I don''t really see a clean way around that. I''ll do the per-directory optimization momentarily; consider it done. Please tell me about how fc-list behaves for you after this change. (I also compiled with -O0 -g, but that *shouldn''t* make a difference. Perhaps the make clean did.) pat
On Tue, 2005-11-29 at 01:13 -0500, Patrick Lam wrote:> Matthias Clasen wrote: > > On Tue, 2005-11-29 at 00:19 -0500, Patrick Lam wrote: > > > >>Matthias Clasen wrote: > >> > >>>The globs change clearly has a big effect. The results of > >>>fc-list | wc -l on my system are as follows: > >>> > >>>cvs20051119: 143 > >>>before globs change: 148 > >>>current cvs: 0 > >> > >>Hmm, there shouldn''t be a difference between before globs change and > >>cvs20051119. However, 0 is a number I''m not reproducing. Can you check > >>your config and try rebuilding your caches? > > > > I just rebuilt my caches with fc-cache from current cvs, and fc-cat > > lists the contents of the cache files as expected. Still, fc-list comes > > up empty. > > For no good reason I had at one point 0 fonts as well. However, I''ve > updated current CVS with a couple of changes, using a more stable API to > get the font filenames. Unfortunately, this is going to hurt the perf > of FcInit. Anyway, I think that the code is now actually correct, and > seems to work fine for me at least. Rebuilding caches doesn''t seem to > help, but recompiling everything might help. > > Globs now check both the full filename and the pathname to see whether > or not they belong to a rejection glob. This can actually be greatly > sped up, come to think of it. The per-directory rejection glob only > needs to be done once per cache directory. Unfortunately, the full > filename still has to be checked; I don''t really see a clean way around > that. I''ll do the per-directory optimization momentarily; consider it > done. > > Please tell me about how fc-list behaves for you after this change. (I > also compiled with -O0 -g, but that *shouldn''t* make a difference. > Perhaps the make clean did.) >Seems to work fine now, thanks. I''ll push a cvs snapshot into rawhide tomorrow, for some wider testing. Matthias
Matthias Clasen wrote:> Seems to work fine now, thanks. I''ll push a cvs snapshot into rawhide > tomorrow, for some wider testing.Good. I''ve committed the patch I just mentioned before, and it seems to work for me. Keith, why don''t we upload this to Debian experimental as well? pat
On Tuesday 29 November 2005 05:19, Patrick Lam wrote:> Matthias Clasen wrote: > > Hmm, I might be missing something, but after updating today, my fc-list > > does not list any fonts anymore. Maybe the optimization was a bit too > > drastic... > > Yeah, there was a problem with the first patch. It''s fixed now though.The patch didn''t touch the code patch fc-list hits at all Greetings, Stephan -- Pace Peace Paix Paz Frieden Pax Pok?j Fri?ur Fred B?ke ?? Hasiti Lap? Hetep Malu M?? Wolakota Santiphap Irini Peoch Shanti Vrede Baris R?j M?r Taika Rongo Sulh Py''guapy ??
Stephan Kulow wrote:> On Tuesday 29 November 2005 05:19, Patrick Lam wrote: > >>Matthias Clasen wrote: >> >>>Hmm, I might be missing something, but after updating today, my fc-list >>>does not list any fonts anymore. Maybe the optimization was a bit too >>>drastic... >> >>Yeah, there was a problem with the first patch. It''s fixed now though. > > The patch didn''t touch the code patch fc-list hits at allThat''s odd. I don''t really know what caused the 0-font problem, then, but it seems to clear up, perhaps on a full recompile. pat