[cairo] 1.1.6 to 1.2.0 performance

[John Ellson]

David Turner wrote:
> James Cloos a écrit :
>> John> Every time I run dot it opens 940 files in /var/cache/fontconfig
>> John> just to resolve "Times-Roman" !
>>
>> That means that fc-cache found 940 (distinct) directories in its
>> search path, cumulative over all runs since /var/cache/fontconfig
>> was last cleared out.
>>
>>   
> How on earth can you get 940 *directories* of fonts. Even the font CDs 
> I've seen only
> use a dozen directories, and they're packed with hundreds if not 
> thousands of fonts.
This number reduced to 168 after I did, as root:
    rm -f /var/cache/fontconfig/*; fc-cache

Shouldn't fc-cache be doing this cleanup?

Stat'ing the same 168 files on every invocation of a program looking for 
the same "Times-Roman" font resolution is still too high.


>
> It's be nice if James could send us the output of "fc-cache -r -v" to 
> see the real numbers,
> at least we wouldn't have to conjecture the problem.
I don't know what "-r " does?  Its not in the man page.

    "fc-cache -r -v"  and "fc-cache -v" both produce 58 records (i.e. 
nearly 58 directories).

Apparently each file in the cache is opened 3 times!

  $ strace fc-match serif 2>&1 | grep open | grep /var/cache/fontconfig | wc
    168     672   14280
  $ strace fc-match serif 2>&1 | grep open | grep /var/cache/fontconfig 
| sort -u | wc
     56     224    4760



>
> I suspect some really horrible thing, like having "/usr/share" in the 
> fontconfig search path,
> and that most of the 940 cache files stored in /var/cache/fontconfig 
> are essentially empty
> because they correspond to directories that don't have any fonts in them.
>> Fontconfig also keeps a single cache file in $HOME for any fonts
>> not covered by the global per-dir cache files, so if you clean out
>> /var/{lib,}/cache/fontconfig it will still work, but instead of
>> open(2)ing and mmap(2)ing the cache files it will have to stat(2)
>> every dir in the search path, see whether any are newer than the
>> cache file, and check out every file in those that are newer to
>> cache them.  So you don't win much.
>>
>>   
> but doesn't stat-ing these 940 directories is going to be a *lot* 
> faster than memory-mapping the
> cache files that would be within them otherwise ?. I'm assuming that 
> not all of them are going to
> change a lot, so a single cache in $HOME could be a performance winner.
>> Moving all of the fonts into a single directory, OTOH, would help --
>> at least on a filesystem that hashes directories -- though it makes
>> management harder. 
>> I don't believe any other OS would do better with fonts spread out
>> over 900+ directories. 
>>   
> An OS like MacOS X uses a single "font server" process. I'm pretty 
> certain it wouldn't have
> any problem with 900+ directories. Of course, this introduces a single 
> point of failure, some
> communication latency and startup slowness (unless caching is used); 
> nothing is free :-)
>
> Regards,
>
> - David Turner
> - The FreeType Project  (www.freetype.org)
>
> PS: Apologies to the Cairo enthusiasts, this thread has little to do 
> with your beloved library.

I have reported this to the fontconfig list, and also to Redhat's Bugzilla
       https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198476

I agree that either of those would be a better place for further 
discussion of this problem.

John