discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The New GNUstep Seems Slow


From: Richard Stonehouse
Subject: Re: The New GNUstep Seems Slow
Date: Fri, 6 May 2011 04:22:42 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]