Re: [cairo] Report for the pango patch and proper profiles

["Xan Lopez" <xan lopez gmail com>]

On 12/1/06, Behdad Esfahbod <behdad 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.o webspace 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