Description of problem: Performance of applications using fontconfig is suffering because it opens 940 files in /var/cache/fontconfig on every invocation. Apparently there is supposed to be a global cache for this, so perhaps it is a fedora-specific problem that this isn't working. Version-Release number of selected component (if applicable): fontconfig-2.3.95-4 freetype-2.2.1-2 How reproducible: 100% Steps to Reproduce: 1. strace /usr/bin/fc-match serif 2>&1 | grep open | grep /var/cache/fontconfig | wc 2. 3. Actual results: 940 Expected results: 1 (if no font updates) Additional info: There is a recent thread on performance in the cairo development list: John Ellson a écrit : > David Turner wrote: >> Hello John, >> >> >>> I suspect the problem is fontconfig. >>> >>> I'm a graphviz developer, and dot, which is a command line utility from graphviz, uses: pango+cairo+fontconfig+freetype >>> Every time I run dot it opens 940 files in /var/cache fontconfig just to resolve "Times-Roman" ! >>> >>> $ strace dot hello.dot 2>&1 | grep open | grep /var/cache/fontconfig | wc >>> 940 3760 79900 >>> >>> Its not a problem specific to graphviz, or even cairo. The fontconfig utility fc-match has the same problem: >>> >>> $ strace /usr/bin/fc-match serif 2>&1 | grep open | grep /var/cache/fontconfig | wc >>> 940 3760 79900 >>> >>> Perhaps this doesn't matter much for a gui appplication, but its a major problem for command line, or web-server applications. >>> >> A recent version of fontconfig should be able to use a global cache, instead of having to re-open all font files >> on startup. Moreover, FreeType 2.2.1 and later contain several speed-ups that might affect performance >> positively when opening a lot of font files. >> >> it'd be interesting to know which versions of these libraries you're using. > > I'm using the latest available version on Fedora Development: > fontconfig-2.3.95-4 > freetype-2.2.1-2 > this is quite strange, please forward this to the fontconfig mailing list, they must be made aware of the problem. Hope this helps, - David
Possibly related. If I do, as root: rm -f /var/cache/fontconfig/* fc-cache then repeat the test above I get 136 instead of 940 hits. So I think fc-cache is not properly cleaning out old cache values before generating new ones. But 136 file open()s is still too many.
Perhaps "fc-cache -r" should be used when new fonts are loaded? The description of "-r" is missing from the fc-cache man page.
Apparently each cache file is open()'ed 3 times: $ strace fc-match serif 2>&1 | grep open | grep /var/cache/fontconfig | wc 168 672 14280 $ strace fc-match serif 2>&1 | grep open | grep /var/cache/fontconfig | sort -u | wc 56 224 4760
Opinion: There needs to be a most-recently-used, per-user/per-application cache of pattern->fontfile resolution. This could be cleared on logout perhaps, or cleared by checking timestamps against the /var/cache/fontconfig directory. There aren't enough hooks into the workings of fontconfig right now for applications to do this themselves, also, in dot's case, fontconfig is buried under cairo and pango making this even more difficult. Conclusion: fontconfig needs to provide this cache. Use case: A utility like dot that opens "Times-Roman" at the same fontsize and slant in two consecutive invocations should only open 1 cache file and 1 font file in the second and subsequent invocations.
This should be reported upstream to be useful. Thanks.
Reported upstream in: https://bugs.freedesktop.org/show_bug.cgi?id=7518
The upstream bug got closed because fontconfig 2.4 is "dramatically faster". I'm going to WONTFIX this, because there is no chance that we are going to do something without upstream support here.