[cairo] 1.1.6 to 1.2.0 performance

[James Cloos]

>>>>> "John" == John Ellson <ellson at research.att.com> writes:

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.

(Side note:  I have /var/lib/cache/fontconfig; I presume some dists
have chosen to move the cache dir from the default.)

I don't beleive it will open any cache files that do not correspond
to a directory in the current search path (as defined by the <dir/>
entries in fonts.conf and its <includes/>), but it is indeed the case
that performance drops as more font dirs are added.  Especially, of
course, if ram is too tight to keep all of those caches paged in.

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.

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.  

I suppose what we really need is a nice font management system that
would make it easy to only have the fonts you actually need at any
given time in the search path.  If, say, Adobe's FontFolio were
installed on a box, having just a few families vs the whole CD in
the search path makes a HUGE difference.

This is not to say there isn't any room for improvement, but lots of
fonts means either lots of RAM or lots of wait....

-JimC
-- 
James Cloos <cloos at jhcloos.com>