[Fontconfig] Application startup performance

[u-pnrz at aetey.se]

On Wed, Jan 13, 2016 at 11:44:26AM +0900, Akira TAGOH wrote:
> On Wed, Jan 13, 2016 at 12:52 AM,  <u-pnrz at aetey.se> wrote:
> >> Here's another alternative -- cache creation could be the responsibility
> >> of fc-cache, but perhaps applications could validate the cache by
> >> checking directory timestamps and loading directories which were out of
> >> date manually (as they do today) but *not* write out that information
> >
> > I would prefer them to skip such directories instead.
> 
> That may introduces a strange problem on a running application when
> fonts is updated if any libraries at the higher layers sets non-zero
> to FcConfigSetRescanInterval(). so if the updates occurs when reading
> caches from applications, we can't avoid I/O operation in fontconfig
> to build a cache. otherwise they can't use such fonts from
> applications right.

Thanks for the explanation Akira. As for checking cache consistency,
I'd rather prefer the applications blindly trust the caches, not check.

IIUC we have though a contract about the possibility to update font
files without updating the caches at the same time :( It would take
time to gradually remove this contract without breaking too much for the
users. On the other side, stating this as obsoleted in the documentation
and putting the deadline for removal in a year would be fair, wouldn't it?

Then everyone would know: you add a font file? let you run fc-cache.

> dunno if we want to get rid of the cache generation from the runtime,
> we may need a dedicated font installlation program to build a cache
> before putting a font into a directory.

Not sure why the generation would have to be done in advance?

If the cache files are being replaced atomically, they only become
inconsistent if a font file has been removed. Otherwise, applications
at rescan notice new caches and hence the added fonts as well,
everything remains fine all the time. Or do I miss something?

Honestly, even though the former behaviour (dir-stat() only) worked
reasonably well in usual scenarios, the runtime cache building attempts
by applications in certain situations are frustrating to say the least (!)
when it implies fetching zillions of files over the network, pushing other
more valuable files out of the cache, without any good reason, because
99.9% of this data is not going to be used. Runtime cache building
is IMHO also confusing and misleading for the users and the
administrators, given the presence of fc-cache as a separate tool
"for this very purpose".

Regards,
Rune