Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 198476 - global cache broken?
global cache broken?
Product: Fedora
Classification: Fedora
Component: fontconfig (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Behdad Esfahbod
Depends On:
  Show dependency treegraph
Reported: 2006-07-11 09:17 EDT by John Ellson
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-27 13:09:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Ellson 2006-07-11 09:17:25 EDT
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):

How reproducible:

Steps to Reproduce:
1. strace /usr/bin/fc-match serif 2>&1 | grep open | grep /var/cache/fontconfig | wc
Actual results:

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
Comment 1 John Ellson 2006-07-12 15:15:13 EDT
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.
Comment 2 John Ellson 2006-07-13 07:39:53 EDT
Perhaps "fc-cache -r" should be used when new fonts are loaded?
The description of "-r" is missing from the fc-cache man page.
Comment 3 John Ellson 2006-07-13 07:52:46 EDT
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
Comment 4 John Ellson 2006-07-13 11:44:35 EDT
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. 
Comment 5 Behdad Esfahbod 2006-07-13 15:41:22 EDT
This should be reported upstream to be useful.  Thanks.
Comment 6 John Ellson 2006-07-13 16:21:40 EDT
Reported upstream in:
Comment 7 Matthias Clasen 2007-03-27 13:09:07 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.