[Fontconfig] performance issue questions

[L. A. Walsh]

Akira TAGOH wrote:
> On Sat, Nov 26, 2016 at 3:38 AM, L. A. Walsh <fonts at tlinx.org 
> <mailto:fonts at tlinx.org>> wrote:
>
>       Generated per dir, yes, but when you choose a directory to
>     update, isn't the time to update it proportional to the number
>     of files in that directory?  Using an extreme case as an example,
>     if you had 10,000 files in that one dir that were all copies
>     of 1 of the files and if the program knew that -- couldn't it generate
>     the info needed for 1 file and, at worse, duplicate it 9,999 times, to
>     avoid the calculation cost for the 9,999 copies (if it "knew" they
>     were copies?).
>
>
> For what to make such copies in the same directory?
---
    "It happens".  My distro used to(? don't think they still do?),
create symlinks to all the fonts that had spaces in them because some
software they had didn't like spaces, so they created "dups" using
underscore.  More than one program has changed case of fonts at
one time or another -- only one that I *knew* that did this was one
that renamed all the font-files to their font-name given internally --
sadly it doesn't work with Unicode-filenames.

>
>       IO race?  Too much I/O for older machines?  Maybe have it
>
>
> No, the race on updating caches.
> As I said, the cache is generated per dirs and the parent cache is 
> also updated.  when caches needs to be updated, that would means fonts 
> were added/updated/deleted or directories containing a font were 
> added/updated/deleted. what if some processes is updating the same cache?
----
    How would parallel processes working on different font-files or
on different caches be any different than if all were updated sequentially?
It seems the risk would be mostly the same.

    Depending on the application, you could likely do the updates in
memory using pipes or similar, though one could also use shared-memory or
even files in /dev/shm, though those could easily overflow memory.

    As for multiple processes trying to update the same cache -- happens
all the time to me when I start multiple copies of gvim, not knowing they
are all going to hang for 12 minutes while the cache is updated, but
then realizing that the system cache is what really need to be updated,
since if I run gvim as a user, and it starts updating -- it can't update
root-owned files -- and indeed, as soon as I su-to-root for something
and run gvim, then root gets hit with a 12-minute wait as well. 

    I've found, usually, if root updates the cache, then the cache
seem to be updated for my user-login(s) as well.
   
> Though fc-cache itself doesn't prevent to do so so far. you could do 
> it with knowing such risks if you want.
----
    It already happens -- if fc-cache doesn't lock the caches, it's
already the case that any user starting an editor will start some update
of some cache if something has changed in the /usr/share/fonts dir.

    That's one of my gripes, is that it takes so long that I often don't
realize what's happening until I've started more than one editor instance.
At that point, I have to try manually killing multiple instances... very
messy.