[Fontconfig] a regression caused by f44bfad235e63bb792c38e16ae1fbd281ec1453b

[u-pnrz at aetey.se]

Hello,

I have just found out that the commit f44bfad235e63bb792c38e16ae1fbd281ec1453b
("Workaround another race condition issue", 2014-06-05)
leads in certain scenarios to a huge performance regression
at applications' startup.

The concerned scenario is:

 - static font data
 - static font configuraton data
 - pregenerated font caches
 - font data on a filesystem with an expensive stat()
   (a network file system with cold metadata cache)

An application using fontconfig with the commit applied seems to issue
stat() on every font file.
In a practical test this took about 90 seconds, which is about the
multiple of the network latency and the number of the available font
files.

We are using specifically Coda file system, but on networks with
remarkable latency most remote file systems would behave similarly,
even if the amount of impact can vary (aggressive prefetching of
metainformation can mask the issue but is not always good/acceptable).

Note that we try to make as many fonts as possible _available_ at the
same time and also that most of them are not being _used_ on a single
given computer, nor have to be pulled into the file system cache over
the network, not even their stat() information.

We noticed the issue because the GUI login time grew dramatically,
I could narrow the reason to this commit.

The change was apparently introduced to make fc-cache more
reliable. Hopefully this can be done differently, without imposing such
a high cost on the applications startup.

For the moment we have no choice but patch the library, reverting the
change, to avoid such pathological situations.

It would be very nice to get a better fix upstream.

Thanks,
Rune