Bug 198476 - global cache broken?
Summary: global cache broken?
Alias: None
Product: Fedora
Classification: Fedora
Component: fontconfig   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Behdad Esfahbod
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-07-11 13:17 UTC by John Ellson
Modified: 2007-11-30 22:11 UTC (History)
0 users

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

Attachments (Terms of Use)

Description John Ellson 2006-07-11 13:17:25 UTC
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 19:15:13 UTC
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 11:39:53 UTC
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 11:52:46 UTC
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 15:44:35 UTC
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 19:41:22 UTC
This should be reported upstream to be useful.  Thanks.

Comment 6 John Ellson 2006-07-13 20:21:40 UTC
Reported upstream in:

Comment 7 Matthias Clasen 2007-03-27 17:09:07 UTC
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.