[Fontconfig] Application startup performance

[u-pnrz at aetey.se]

On Thu, Jan 14, 2016 at 11:29:33AM +0900, Akira TAGOH wrote:
> > Then everyone would know: you add a font file? let you run fc-cache.
> 
> We could try to add a boolean flag to the configuration for
> enabling/disabiling that check at the runtime though. we definitely
> need to test it carefully if it doesn't affect a lot. or only if the
> font directory is on nfs.

I would call for caution against assuming any nfs-specific behaviour.
(For the record, we use Coda file system, not NFS; NFS is not up to
the task)

Even detecting the use of a somehow "networked" file system is hardly
portable and prone to errors. Please do not.

There are literally dozens of network file systems with different
properties, limitations and bottlenecks. Any application or library
specifically checking for a certain file system type(s) is incomplete
by design.

[Networked filesystems are also a quite complicated field; to be able to
 properly account for file system specifics one should have the knowledge
 of a file_system_developer, which most of developers are not. Worse,
 the behaviours change with versions and implementations. NFSv4 behaves a
 lot differently than NFSv3, Arla AFS does not behave the same as OpenAFS.
 
 In some situations it is stat() which is expensive, in other situation
 it is open() or lseek() which take a long time, in third situations it
 is unlink() which should be avoided, and so on.]

> > Not sure why the generation would have to be done in advance?
> 
> Because fontconfig on running applications will tries to update the
> cache when it is detected.

If we end the contract allowing runtime updates, then we are safe.

> > 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?
> 
> Depends. if fonts has critical changes (e.g. urw-fonts removed
> Cyrillic glyphs from Century Scroolbook L) or renaming family name
> etc, you'll see inconsistency between caches and fonts.

I see, there are more cases when this leads to breakage, than a removal
of a font file, but I do not feel that they are crucial.

The changes like you describe are usually done not by the users but by
system packagers, who already do run fc-cache. In any case, the possible
breakage is limited in time, until fc-cache is run.

> there are no way to know in advance what fonts are actually being
> used. To get rid of the runtime cache generation, we need to have any
> way to ensure that caches keeps up-to-date when fonts is
> installed/updated.

Exactly. IMHO documentation is the best means here, stating that
fc-cache has to be run after any change in the font collections,
the requirement becoming mandatory, say, 2018-01-01.

Putting this in the man page(s) and in the Changelog looks like a fair
approach to a change - with either my system packager hat or my user
hat on.

Of course, having a configure switch to disable the run time generation
would be very welcome, to let the distros/packagers make the transision
as early as they may wish. Half way from now the switch could change
the default from "off" to "on" and at the end of the announced period
the switch and the corresponding runtime generation code could be removed.

Thanks Akira for your work on fontconfig.

Regards,
Rune