[cairo] Report for the pango patch and proper profiles

[Xan Lopez]

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
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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/cairo/attachments/20061201/722decdc/attachment.html