As it currently stands, fc-cache seems to struggle quite a bit when handling CJK fonts - in this example, the Noto Sans CJK family. On a Sandy Bridge laptop with an i7-2860QM processor, the process could take up to a minute, during which it is impossible to run new graphical/X11 programmes - Firefox could also lock up.
On my setup with Freetype 2.8.1 and Fontconfig 2.12.6, with Noto Sans (full set) and Noto Sans CJK installed, fc-cache could take up to 2 minutes to finish the process (!).
A wonder would be, could fc-cache implement...
- Some sort of optimisation for these larger fonts?
- Parallelisation, so that it could take advantage of a multi-core/multiprocessor system? As it currently stands, fc-cache only utilises one processor core.
I do apologise for the lack of technicality in this bug report, but please take this into your consideration - I can provide aid with clarification or operations if needed.
And I should make it clear that this issue is not limited to x86_64. On other architectures, such as a slower ARMv7 processor, this issue could be indefinitely magnified - say, a 10+ minute time consumption, making this issue even less bearable.
*** This bug has been marked as a duplicate of bug 64766 ***
Is it fixed with master / newer releases? It should be. Looks like 2.12.6 is the last slow release.
(In reply to Behdad Esfahbod from comment #3)
> Is it fixed with master / newer releases? It should be. Looks like 2.12.6 is
> the last slow release.
If that's the case this is good news... I have tried .92 just yesterday but it seemed to not like my old fontconfig xmls, spewing out a lot of parsing errors - and reverted to "defaults", don't remember the specifics. Is there a change resulted the change in fontconfig XML formatting?
Otherwise I would have to get back to you with that. I'll do a time comparison with .92 vs .6.
Another thing is that it doesn't seem like the `faster` branch changes as referenced in #64766 is merged with the master - could you clarify?
I have re-opened the report as there's not a conclusive claim to improved performance in this case.
That branch didn't merge, but different changes did. Check commits I made on 2017-09-12.
No idea what changed re config syntax. Akira should know.
(In reply to Mingcong Bai from comment #5)
> If that's the case this is good news... I have tried .92 just yesterday but
> it seemed to not like my old fontconfig xmls, spewing out a lot of parsing
> errors - and reverted to "defaults", don't remember the specifics. Is there
> a change resulted the change in fontconfig XML formatting?
No idea. what errors did you see?
such drastic changes shouldn't be made in config since 2.12.6
> Another thing is that it doesn't seem like the `faster` branch changes as
> referenced in #64766 is merged with the master - could you clarify?
> I have re-opened the report as there's not a conclusive claim to improved
> performance in this case.
As we decided this is a dup of #64766, this obviously improved. see:
$ time fc-cache -f /usr/share/fonts/google-noto-cjk
fc-cache -f /usr/share/fonts/google-noto-cjk 186.64s user 0.43s system 96% cpu 3:13.38 total
On git master
$ time ./build/fc-cache/fc-cache -f /usr/share/fonts/google-noto-cjk
./build/fc-cache/fc-cache -f 0.19s user 0.04s system 9% cpu 2.281 total
Hope that helps
I can confirm that with 2.12.92 the speed at which `fc-cache -sfv` runs has been exponentially improved...
real 4m30.407s 92.46%
real 0m8.913s 77.32%
I will mark this resolved. However, if you guys could consider a look at https://bugs.freedesktop.org/show_bug.cgi?id=105102 it would be much appreciated. Thanks for your work!