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.
Exactly
(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: On 2.12.6 $ 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... 2.12.6: real 4m30.407s 92.46% user 4m8.472s sys 0m1.553s 2.12.92: real 0m8.913s 77.32% user 0m6.344s sys 0m0.549s 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!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.