fontconfig 2.9.0 slows down program start, etc.

[eric.lebigot@…]

There are at least two reports of fontconfig 2.9.0 slowing things down at startup (and also disabling some font anti-aliasing).

Here are the relevant tickets:

• #33752
• #33744

Reverting to 2.8.0 can fix the problem.

Good luck with the fix. :)

[ryandesign (Ryan Carsten Schmidt)]

Jeremy, do you think this might have something to do with the patches you made for me that went into the 2.9.0 port?

[su-v]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

I don't think it has to do with the patches in general. The filenames of the caches changed in 2.9.0, and the patches that I provided made us work again with the new cache scheme. It's possible that this startup lag is just because the font cache is being rebuilt, but that should only be the case on the *first* execution.

I don't see any such issue on my machine.

Can you please retry to see if the slowness has gone away? If it is still present, please run 'sudo sysdiagnose' or hit the ctrl-cmd-opt-shift-<period> key sequence to trigger a sysdiagnose. After ~5 minutes a finder window will open with your diagnosis report. Please send it to me in email for analysis (it contains some system logs which may contain personal info like what applications your run or have installed)

[mklein-de (Michael Klein)]

Cc Me!

[mklein-de (Michael Klein)]

On my machine the cache seems completely ineffective with 2.9.0.

Consecutive invocations of fc-cache -v give always the same output:

$ fc-cache -v
/usr/share/fonts: skipping, no such directory
/usr/X11/lib/X11/fonts: caching, new cache contents: 0 fonts, 10 dirs
/usr/X11/lib/X11/fonts/100dpi: caching, new cache contents: 398 fonts, 0 dirs
/usr/X11/lib/X11/fonts/75dpi: caching, new cache contents: 398 fonts, 0 dirs
/usr/X11/lib/X11/fonts/OTF: caching, new cache contents: 23 fonts, 0 dirs
/usr/X11/lib/X11/fonts/Speedo: skipping, existing cache is valid: 23 fonts, 0 dirs
/usr/X11/lib/X11/fonts/TTF: caching, new cache contents: 23 fonts, 0 dirs
/usr/X11/lib/X11/fonts/Type1: caching, new cache contents: 29 fonts, 0 dirs
/usr/X11/lib/X11/fonts/cyrillic: skipping, existing cache is valid: 29 fonts, 0 dirs
/usr/X11/lib/X11/fonts/encodings: caching, new cache contents: 0 fonts, 1 dirs
/usr/X11/lib/X11/fonts/encodings/large: caching, new cache contents: 0 fonts, 0 dirs
/usr/X11/lib/X11/fonts/misc: caching, new cache contents: 59 fonts, 0 dirs
/usr/X11/lib/X11/fonts/util: caching, new cache contents: 0 fonts, 0 dirs
/Library/Fonts: caching, new cache contents: 220 fonts, 1 dirs
/Library/Fonts/Corel: caching, new cache contents: 159 fonts, 0 dirs
/Network/Library/Fonts: skipping, no such directory
/System/Library/Fonts: caching, new cache contents: 50 fonts, 0 dirs
/opt/local/share/fonts: caching, new cache contents: 0 fonts, 2 dirs
/opt/local/share/fonts/libwmf: caching, new cache contents: 13 fonts, 0 dirs
/opt/local/share/fonts/urw-fonts: caching, new cache contents: 35 fonts, 0 dirs
/Volumes/Users/michael/.fonts: caching, new cache contents: 1 fonts, 0 dirs
/Volumes/Users/michael/Library/Fonts: caching, new cache contents: 43 fonts, 0 dirs
/opt/local/var/cache/fontconfig: not cleaning unwritable cache directory
/Volumes/Users/michael/.fontconfig: cleaning cache directory
fc-cache: succeeded

While fc-cache runs, the file $HOME/.fontconfig-be32d4.cache-3 is constantly being updated. After that, inspecting that file with strings shows only fonts from /Volumes/Users/michael/Library/Fonts, but no other paths. The directory $HOME/.fontconfig is empty.

If I pass /Volumes/Users/michael/Library/Fonts to fc-cache after fc-cache, the cache is found:

$ fc-cache -v /Volumes/Users/michael/Library/Fonts/
/Volumes/Users/michael/Library/Fonts: skipping, existing cache is valid: 43 fonts, 0 dirs
/opt/local/var/cache/fontconfig: not cleaning unwritable cache directory
/Volumes/Users/michael/.fontconfig: cleaning cache directory
fc-cache: succeeded

For any other directory the cache is rebuilt.

[duncan.rumbold@…]

I haven't taken the time to understand what's going on in the patch files with it's various architecture option magic but, for what it's worth, excluding the patch files from the build (by commenting them out of the portfile and installing from source with the 'port -s' option) seems to fix the cache writing problem with 2.9.0.

[jeremyhu (Jeremy Huddleston Sequoia)]

The patch files just set the path names for the cache files. Even if the patches were not used, you would be hitting the same issue.

[su-v]

Replying to jeremyhu@…:

Even if the patches were not used, you would be hitting the same issue.

Can't confirm: on OS X Lion 10.7.2, Xcode 4.2.1, the average launch time of inkscape is noticeably slower with fontconfig @2.9.0_0:

fontconfig @2.8.0_0:   ~11.2 sec
fontconfig @2.9.0_0:   ~27.6 sec
fontconfig @2.9.0_1:   ~11.7 sec

fontconfig @2.9.0_1: local revision without the patches from r90994
inkscape launch time measured with repeated execution of

$ time inkscape --verb=FileClose

The slow-down with the patched version of fontconfig 2.9.0 affects each launch of the application, not only the first run.

[jeremyhu (Jeremy Huddleston Sequoia)]

That seems odd. Can you try with this patch instead:

​http://cgit.freedesktop.org/fontconfig/commit/?id=8cc4498122b17843b00ec3eebdd7a7d8d59cb7ff

[su-v]

Replying to jeremyhu@…:

That seems odd. Can you try with this patch instead:

​http://cgit.freedesktop.org/fontconfig/commit/?id=8cc4498122b17843b00ec3eebdd7a7d8d59cb7ff

With this patch (instead of the two from r90994), launch times of inkscape are about the same as with fontconfig 2.8.0 (and 2.9.0 without any patches), about ~11.5 sec.

[jeremyhu (Jeremy Huddleston Sequoia)]

Weird, that should have absolutely no effect... sill, I'll look into it. In the mean time, we can just use the other patch instead...

[duncan.rumbold@…]

I can also confirm that 2.9.0 + the latest patch posted here brings the times back to that of 2.8.0, and that an fc-cache -v shows that cache files don't need to be recreated once they already have been. This seems to be the same behaviour as 2.9.0 without any patches at all.

I don't know if this is of interest but on my system, font cache files with 2.8.0 have filenames such as: /opt/local/var/cache/fontconfig/0030f3da31c070a8906b7c5926cc3913-x86-64.cache-3

while 2.9.0 with either no patches or the latest one above (i.e. the variations of 2.9.0 that 'work') creates files such as: /opt/local/var/cache/fontconfig/0030f3da31c070a8906b7c5926cc3913-le64.cache-3

2.9.0 with the two default patches (that cause the problem) doesn't generate such files, but did leave a trace of something: /opt/local/var/cache/fontconfig-le64d8.cache-3

It's as if 2.9.0 with the default patches has missed out a directory separator and the actual cache filename.

[joergahrens (Jörg Ahrens)]

Cc Me!

[joergahrens (Jörg Ahrens)]

Cc Me!

[joergahrens (Jörg Ahrens)]

Cc Me!

[duncan.rumbold@…]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, that helps. Thanks. It looks like what is probably happening is that all the cache files are thrashing with eachother because they're missing that identifier somewhere... in either event, we have the solution, so hopefully ryan can just push it. thanks for the additional info.

[ryandesign (Ryan Carsten Schmidt)]

Replying to duncan.rumbold@…:

It's as if 2.9.0 with the default patches has missed out a directory separator and the actual cache filename.

Similar here: I note that I have a file in my home directory called ".fontconfig-le64d8.cache-3", created yesterday. (This is the only one.) It has the same checksum as the file "~/.fontconfig/0030f3da31c070a8906b7c5926cc3913-x86-64.cache-3" created in January.

I'll commit the new patch.

[ryandesign (Ryan Carsten Schmidt)]

r91265

[eric.lebigot@…]

Thank you so much for your prompt fix!