[Fontconfig] performance issue questions

[L. A. Walsh]

Having sat through another gvim startup taking nearly
12 minutes (the font-config step took 704 seconds as
timed by the parent), I was thinking about this
again.


1) If I don't use 32-bit programs (I don't install them) does the
32-bit font info need to be computed and cached?

2) does the info program detect hardlinks and not duplicate
the calculation but reuse it?

3) Why aren't parallel processes used?  Most users have at
least 4-6 processors these days (my font cache is on a
server w/12 processors) and could get a substantial
reduction if the work was split among multiple processes.

4) why not run the font-config every night to check if things
are up-to-date.  That would have painlessly updated my
cache before I next used it. 

----

Of note -- raw, my fonts take 19G for 36119 fonts.  However, many
of those end up being duplicates due to name changes from various
sources (windows (shortening, or case mods), or programs replacing
spaces with underscores, etc).  As a result, it pays to run
a "dedup" program over the dir periodically (or after installs).

A dedup run over the raw dir shows:
Paths: 36119, uniq nodes: 36119, total_size: 18GB (19GB allocated).
11GB in 15774 duplicate files found in 92.58 seconds.  (103.09s total)
---
I.e. almost half of the files are dups -- with the dedupper
linking duplicates (as it doesn't know which name(s) are used
by which programs).

Given the above, maybe you can see why I asked the above
4 questions... ;-)

Thanks,
linda