On 12/1/06, Behdad Esfahbod <[EMAIL PROTECTED]> wrote:
On Wed, 2006-11-29 at 09:24 -0500, Xan Lopez wrote on cairo list: > > Anyway, thanks to the nice guys from opened-hand I received the patch > that fixes the symbol resolving brokeness of my oprofiler, so I can > now provide sane profiles. I'm attaching profiles for cairo, pango and > pangocairo from a timetext run. Can you attach a merged profile too (one for all libraries, oprofile does that I believe)? With separate profiles, it's not as easy to see what's going on, without guessing and all...
Sure, I tried once but it was too big for the list. I've got my fd.owebspace already, I'll put the whole set of profiles there tonight, hopefully. (...) and now there's only 1 get_glyph_extents() calls per glyph per expose.
That one is a bit harder to fix, unless one caches per-line or per-item extents. There's actually a patch for this already: http://bugzilla.gnome.org/show_bug.cgi?id=135683 The problem is, PangoLayout has API that gives away pointer to internal structures, such that you can modify the glyph widths, and that is legitimate use. For example Firefox+Pango uses that to justify lines. So I was under the impression that we cannot meaningfully cache much, until I figured, well: we can cache, until the user asks for that evil pointer! So, unless we have handed out a pointer to internal stuff, we can cache. And even when we have given the pointer away, we can cache as part of a single pango operation. So, I'm going to look more into this, and come up with a sensible scheme that doesn't introduce regressions. With that in place, it may make sense to revert some of my pango_glyph_string_get_width() uses above and use the cached values; maybe not. Donno.
Looking forward to it, with your patches you dropped glyph extents calculation from the first place, but it's still quite high in the profile :) Anyway, that's all for now. Some numbers:
For timetext.c [2]: Before: Drawn label 112412 times. Average time spent drawing (in seconds): 0.000105 After: Drawn label 123871 times. Average time spent drawing (in seconds): 0.000063 So, in this case, the expose time was improved 40%, and overall performance was improved 10%. I expect (much) higher numbers for the latter on tiny gadgets, but can't tell unless I'm offered one ;-).
Well, I'm not getting numbers *that* impressive here, don't exactly know why. Might just be that our environments are quite different beasts, might be that I'm doing something wrong. Anyway, the results are quite impressive: Before: Drawn label 2811 times. Average time spent drawing (in seconds): 0.001882 After: Drawn label 2903 times. Average time spent drawing (in seconds): 0.001702 And if you want a tiny gadget just forward me a postal address to ship it ;) Offtopic:
I use a small toy of mine to write /probes/ that can do cool things about what library calls are being made without having to compile/install pango all the time. It's a tiny script called bprobe, available from GNOME CVS. For example, this is the probe I used to figure out what's going on: http://cvs.gnome.org/viewcvs/*checkout*/bprobe/probes/pango-glyph_extents.probe?rev=HEAD However, this only works because Pango doesn't have the machinery to avoid PLT usage for local symbols. That's another thing to look into, may have measurable performance (and size) improvements on smaller devices.
Looks pretty cool, I'll certainly give it a try.
[1]http://lists.freedesktop.org/archives/cairo/2006-November/008628.html > [2]http://folks.o-hand.com/jorn/pango-benchmarks/timetext.c Cheers, -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759
_______________________________________________ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list