Re: performance issue questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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 . |wc
 44251   64142 1277516
1.03sec 0.19usr 0.04sys (23.35% cpu)

Ishtar:/usr/share/fonts> time . |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

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux