[Fontconfig] performance issue questions

[L. A. Walsh]

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.