[Fontconfig] Application startup performance
keithp at keithp.com
Tue Jan 12 07:29:44 PST 2016
u-pnrz at aetey.se writes:
> I would rather postulate fc-cache to be run and risk ignoring some fonts
> until this is done. Is the risk really significant? Distros run fc-cache,
> users who add fonts on their own would know they have to run fc-cache.
Yes, it's pretty clear we've gotten distros to understand that running
fc-cache is required after installing fonts.
> What makes me unconfortable is applications doing huge i/o operation at
> startup just because of a certain library being used. Then neither
> the application developer nor the user have some real power over the
It's failures within fontconfig that cause this
> I would be even more uncomfortable if there will be some locks involved
> or some daemons would be expected to run just to be able to rely on
> fontconfig. Explicit cache creation looks like the cleanest solution.
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
back to the disk which would avoid the race conditions present in the
current environment. fc-cache could then use some kind of per-directory
locking to avoid races in generating the information there, which should
make the directory timestamps reliable enough to not need applications
to scan every directory manually at startup time.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 810 bytes
Desc: not available
More information about the Fontconfig