I've applied your change as a patch to gnustep-back version 0.20.0 and GWorkspace now starts up in less than 5 seconds. Thanks very much for the speedy fix!
On Thu, May 05, 2011 at 02:46:07PM -0600, Eric Wasylishen wrote: > Sorry, this is indeed my fault. > > I committed a simple fix which caches the NSCharacterSet in CairoFaceInfo and > it seems to fix the problem. A better fix would be to cache the matched > pattern as you said, but I think the main bottleneck is fixed. > > At some point I'd like to replace most of CairoFontInfo / CairoFaceInfo with > the new code Niels wrote for Opal, so we can stop using the cairo toy api and > draw glyphs properly, but I'm not sure when I'll have a chance to do this. > > Eric > > On 2011-05-05, at 3:03 AM, Fred Kiefer wrote: > > > I just run kcachegrind over the callgrind result from Ink and from that I > > would pick out the new method [CairoFaceInfo characterSet] that Eric added > > on the 27th of March as the culprit. On my machine this seems to use up 90% > > of the execution time of Ink. I don't trust any profiling numbers, still > > this is an important hint, where the slowdown might come from. > > > > I don't quite understand how this could happen, as this method gets called > > only once per font. The main time there is spend in FcFontMatch, which also > > gets called from fontFace, but doesn't result in a problem there. As it > > turns out FcFontMatch gets called 10 times (my not so scientific numbers, > > invent your own if you prefer) more often from characterSet than it is > > called from fontFace and the reason for this simply is that we cache the > > fontFace but not the characterSet. The solution should be as simple as to > > cache the characterSet as well. Or even better, use a common cache for the > > resolved pattern. > > > > Eric, what is your thinking on this? By now you are more familiar with the > > cairo backend than I am. > > > > > > > > On 28.04.2011 21:03, Richard Stonehouse wrote: > >> This was with the cairo backend. > >> > >> Rebuilds with the art and xlib backends work fine - run at the > >> expected speed. > >> > >> The installed cairo is libcairo.so.2.10800.10 from openSUSE 11.3 > >> package cairo-1.8.10-3.1.i586; gnustep-back 0.18.0 worked OK with > >> this. > >> > >> There is another libcairo on the system, installed by vmware in one > >> of its own directories, but I'm pretty confident that gnustep-back is > >> linked against the correct libcairo and not the spurious one. > >> > >> openSUSE 11.4, which I've downloaded but not yet installed, has a new > >> version of libcairo: /usr/lib/libcairo.so.2.11000.2 in package > >> libcairo2-1.10.2-6.9.1.i586. I'm planning to install it over the > >> weekend so will see whether the problem goes away. > >> > >> Please let me know if there's anything else I should try. > >> > >> On Thu, Apr 28, 2011 at 11:08:23AM +0100, Fred Kiefr wrote: > >>> I don't know about any specific reason why GNUstep should now be > >>> slower. This seems to be an important issue to investigate. Which > >>> bacend are you using? A wrong backend is the most common reason > >>> for a slowdown. If this isn't the case we need to use tools to > >>> find out where the time gets spend. I will send a mail on this > >>> next week, when I am back home. > > > > > > > > _______________________________________________ > > Discuss-gnustep mailing list > > Discuss-gnustep@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Richard Stonehouse _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
