Hi all,
2016-11-24 7:57 GMT+01:00 Jerry Casiano <jerrycasiano@xxxxxxxxx>:
[...]
> I mean, if you just have to have 15,000 duplicates and 20,000+ font
> files active at all times then it is what it is.
The fact that he has 15,000 duplicates and 20,000+ font files just
makes the problem more evident, but the problem also exists on systems
with less font files and few or no duplicates. By googling around a
bit it is not difficult at all to find discussions about problems
related to the fontconfig cache -- not only from it being "slow",
which is always subjective, but to the fact that applications have no
way to tell whether the cache has to be rebuilt, so users often see
noticeable delays (sometimes minutes!) and they don't even know what
is going on ("program hangs at startup" is what they'd report).
And that's for desktop systems with lots of RAM and CPU power. Go to
the other end of the spectrum and you can see similar issues. On an
embedded platform based on a Cortex A7 where I used fontconfig, the
startup time on first boot was about one minute. Subsequent boots are
below the 10 second mark. This particular system had three fonts, and
no duplicates.
The point I'm trying to make is that, regardless of whether having
20,000+ font files and 15,000 duplicates is a common case or not,
performance of the fontconfig cache is a topic that deserves
attention.
Best,
Guillermo Rodriguez Garcia
guille.rodriguez@xxxxxxxxx
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig
