Keith Packard wrote:
We might as well just stop attempting to automatically manage the caches
and require that users run fc-cache manually whenever they change the
set of installed fonts. That would push the whole problem out of
fontconfig and onto the user or distribution...
---
That would be preferable, since the user might want to install
100 fonts and then build a cache rather than have it rebuilt with
each font installed.
Although, I wonder if doing some per-directory locking while scanning
might not help with this; essentially have one process hold a lock on
the directory while scanning and make other processes wait for the lock
to go away (with a timeout).
---
NOT that it would be idea, but even if one were to stat EVERY
file under /usr/share/fonts, it doesn't take "that long"...
Ishtar:/usr/share/fonts> dropcaches
5.37sec 0.02usr 4.91sys (91.82% cpu)
# w/cold cache for 44k objects:
Ishtar:/usr/share/fonts> time find . -mtime +900000
5.50sec 0.04usr 0.95sys (18.19% cpu)
# w/warm cache: <1s
Ishtar:/usr/share/fonts> time find . |wc
44251 64142 1277265
0.11sec 0.05usr 0.09sys (130.28% cpu)
Same thing using async io:
Ishtar:/usr/share/fonts> dropcaches
0.08sec 0.02usr 0.04sys (73.26% cpu)
Ishtar:/usr/share/fonts> time treescan-aio.pl . |wc
44251 64142 1277516
1.03sec 0.19usr 0.04sys (23.35% cpu)
Ishtar:/usr/share/fonts> time treescan-aio.pl . |wc
44251 64142 1277516
0.13sec 0.14usr 0.04sys (137.56% cpu)
That's one reason I asked about updating only the
cache for 1 font, since rather than reconstructing the whole
thing, a simple find cmd could really narrow down the work that
needs to be done.
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig
