If this was anybodies specific fault, then it was mine. I should have
reverted your change right after you applied it as we were already in
code freeze mode at the time and most of the testing had already taken
place. But I liked the general idea of it (still do!) and didn't check
the details.
It just shows that we should respect code freeze periods a lot more than
we do currently.
Fred
On 05.05.2011 22:46, 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
