[cairo] Report for the pango patch and proper profiles
xan.lopez at gmail.com
Fri Dec 1 06:28:01 PST 2006
On 12/1/06, Behdad Esfahbod <behdad at behdad.org> 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
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:
> 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 :
> Drawn label 112412 times. Average time spent drawing (in seconds):
> Drawn label 123871 times. Average time spent drawing (in seconds):
> 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):
After: Drawn label 2903 times. Average time spent drawing (in seconds):
And if you want a tiny gadget just forward me a postal address to ship it ;)
> 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:
> 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
Looks pretty cool, I'll certainly give it a try.
> > http://folks.o-hand.com/jorn/pango-benchmarks/timetext.c
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety, deserve neither Liberty nor Safety."
> -- Benjamin Franklin, 1759
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cairo