Hi, This is a known issue in Chrome: https://code.google.com/p/chromium/issues/detail?id=266214#c15 We tried fixing it a while back, but that broke some other stuff. No one is currently working on it. I'll see if I can give it another push. behdad On 14-05-23 05:37 AM, Guangmu Zhu wrote: > Hi, > > It confused me very often when I was using Chrome that libfontconfig.so > occupied too much CPU resources only when Chrome was loading a page with > Chinese fonts such as SimSun and Microsoft YaHei. It haven't happened > with English fonts. Actually, the .so was always the top or second in > `perf top`. > I have read some source codes and downloaded the debug pkg. In .so's > DSO, a function not in symbol table usually took 90+% resources. The > address was located between 0x1e190-0x1e360. According to debug pkg's > symbol table and disassembled codes with objdump, all of these are a > series of FcStrCaseWalker* functions and Ucs-Utf transcoding functions. > And the function FcStrCaseWalkerNext's address(0x1e190) would appear > usually. > I read some source codes about FcStrCaseWalkerNext and its caller, but > they seem harmless. And I tried some sample programs and a program I > wrote, all worked very well. I guess, perhaps the function was called > very often when using FcConfig*, FcPattern*, FcFontSet* to GetObject or > GetString. > On my computer(Thinkpad X240s i7-4500u), the problem could make devices' > temperatures rise rapidly from 113 ℉ to 149 ℉ and cool down slowly for > the .so would occupy much CPU resources always. Maybe someone could tell > me how to deal with it? > > Thanks in advance. > > _______________________________________________ > Fontconfig mailing list > Fontconfig@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/fontconfig > -- behdad http://behdad.org/ _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
