Red Hat Bugzilla – Bug 198476
global cache broken?
Last modified: 2007-11-30 17:11:37 EST
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):
Steps to Reproduce:
1. strace /usr/bin/fc-match serif 2>&1 | grep open | grep /var/cache/fontconfig | wc
1 (if no font updates)
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:
this is quite strange, please forward this to the fontconfig mailing list, they
must be made aware of the problem.
Hope this helps,
Possibly related. If I do, as root:
rm -f /var/cache/fontconfig/*
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
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.
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:
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.