[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The New GNUstep Seems Slow
Re: The New GNUstep Seems Slow
Thu, 05 May 2011 11:03:40 +0200
Mozilla/5.0 (X11; U; Linux x86_64; de; rv:188.8.131.52) Gecko/20110414 SUSE/3.1.10 Thunderbird/3.1.10
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
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
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
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.
- Re: The New GNUstep Seems Slow,
Fred Kiefer <=
- Re: The New GNUstep Seems Slow, Eric Wasylishen, 2011/05/05
- Re: The New GNUstep Seems Slow, Fred Kiefer, 2011/05/05
- Re: The New GNUstep Seems Slow, Richard Stonehouse, 2011/05/05
- Re: The New GNUstep Seems Slow, Fred Kiefer, 2011/05/06
- Re: The New GNUstep Seems Slow, Dr. H. Nikolaus Schaller, 2011/05/06
- Re: The New GNUstep Seems Slow, Richard Frith-Macdonald, 2011/05/06
- Re: The New GNUstep Seems Slow, Sebastian Reitenbach, 2011/05/06
- Re: The New GNUstep Seems Slow, Eric Wasylishen, 2011/05/06
- Re: The New GNUstep Seems Slow, Adam Fedor, 2011/05/06
- Re: The New GNUstep Seems Slow, Fred Kiefer, 2011/05/07