[cairo] Cairo 1.3 performance loss

[Carl Worth]

On Mon, 29 Jan 2007 13:25:13 +0200, Jorn Baayen wrote:
> Now, if we look at the GtkEntry drawing test for cairo 1.2.4, we see
> that a GtkEntry was drawn 6181 times. This figure is 6035 for cairo
> 1.3.12, which is a loss of ~ 2%.

OK, so you're comparing the numbers that appear in timewidgets.txt in
different directories. I hadn't been able to figure that out before.

Now, can you still help me understand where those numbers come from so
we can decide if they actually mean anything?

Here's what we have to work with:

Drawn widget 6181 times. Average time spent drawing (in seconds): 0.001513
[http://folks.o-hand.com/~jorn/cairo-benchmarks/1.2.4/gtkentry/timewidgets.txt]

Drawn widget 6035 times. Average time spent drawing (in seconds): 0.001572
[http://folks.o-hand.com/~jorn/cairo-benchmarks/1.3.12/gtkentry/timewidgets.txt]

If you're going to compare the total counts of widgets drawn, is this
a count of the total drawn within a fixed time? How much time is that?
And how precisely is it controlled? Are we really talking about
comparing two single-sample measurements?

I'm not sure where the code is that computed this stuff, but if we
guess that a simple average went into the above, we can compute what
the fixed times might have actually been:

	time1 = 6181 * 0.001513 = 9.351853 seconds
	time2 = 6035 * 0.001572 = 9.48702 seconds

Which is to say, that the time isn't actually very fixed at all---it
differs by ~ 1.5% between these two samples. In other words, by about
the same amount as the difference you are seeing in the result,
(though, as it happens to turn out in this case, in the other
direction).

What I still haven't seen in any of the above is any indication of how
stable the numbers are from one run to the next.

> I don't think this analysis is correct. The percentages we are looking
> at represent what part of all the time spent in all functions over the
> whole system stack was spent in our functions. The time the tests were
> run is constant, only the number of draws achieved differ.

OK. So you're giving yet another reason that we really can't learn
much from comparing percentages from different profile runs. They
aren't measuring what we care about, (which is, for example, "how much
time is spent in the tessellator for each widget draw").

> Perhaps more interesting would be to look purely at the cairo profiles,
> because the percentages here are relative to the time spent in cairo
> only. Let's say that one draw using 1.2.4 takes 100 bogoticks inside
> cairo, and one draw using the 2% slower 1.3.12 102 bogoticks inside
> cairo.

You can't do that. The slowdown you measured is 2% overall. Since
cairo contributes only to a fraction of the total time, and assuming
that cairo is the only thing that's slower[*], cairo's time should
increase by more than 2%. So assuming 100 and 102 bogoticks for cairo
alone is invalid.

We've established that there's increased overhead from the tessellator,
and I'm glad to help address that regression, (see below). But I remain
unconvinced as to how stable your measure of overall slowdown is nor
that we've successfully identified everything that contributes to it.

> It's drawing just rectangles.

Good to know.

One thing we recently added is special-cased code for stroking
rectilinear paths. When I did that work I expected that I would end up
adding a new rectangle primitive to cairo's internal path structure.

I didn't end up doing that since the rectilinear stroke case shows up
when stroking non-rectangular shapes, (such as an L-shape, etc.). But
that might be something that would useful here for eliminating all the
tessellation overhead for filling rectangles. We've already got
special-case code for tessellating any convex quadrilateral, (see
_cairo_traps_tessellate_convex_quad), so all that's missing is
something to tell the path code that it can call into that rather than
_cairo_bentley_ottmann_tessellate_polygon.

So a new rectangle primitive should do the trick here.

> > http://people.freedesktop.org/~jrmuizel/libcairowrap-0.1.tar.gz
>
> Thanks, this is being very helpful.

Good. I'm glad. If you can generate a cairo/perf case demonstrating
the performance problem of interest, then I would be quite glad to do
the work to add a rectangle primitive to cairo_path_fixed_t and using
_cairo_traps_tessellate_convex_quad to tessellate it.

> At the very least the tests should benefit from the double-to-fixed
> optimizations.

Were the measurements from from intermediate releases, (between 1.2.4
and 1.3.10) that showed these benefits? Would you be willing to
git-bisect to chase things down?

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070129/e548834e/attachment-0001.pgp