Am 06.05.2011 um 09:38 schrieb Fred Kiefer: > Great! Now what should we do about this? Release a bug fix for back? That way > we would have a different version number for back and the corresponding gui. > But will this cause any harm?
That is what minor and subminor version numbers are used for in many other projects. I.e. 1.2 => base release 1.2.1 => first fix 1.2.2 => second fix I.e. Back could go from 0.20.0 => 0.20.1 while GUI could stay and I think most people would understand this in the way that both are Version 0.20 and Back has got one fix. Or you release an unchanged version of GUI. BR, Nikolaus > > With all the great changes from Eric in gui we should only do a new full > release after completing that change cycle. I would expect that this take up > at least two more months. An intermediate bug fix release sounds appropriate. > > Fred > > -------- Original-Nachricht -------- >> Datum: Fri, 6 May 2011 04:22:42 +0100 >> Von: Richard Stonehouse <[email protected]> >> An: Eric Wasylishen <[email protected]> >> CC: Fred Kiefer <[email protected]>, "[email protected]" >> <[email protected]> >> Betreff: Re: The New GNUstep Seems Slow > >> 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 >>>> [email protected] >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> >> -- >> Richard Stonehouse >> >> _______________________________________________ >> Discuss-gnustep mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
