[cairo] Cairo 1.3 performance loss

[Jorn Baayen]

Hi,

On Mon, 2007-01-29 at 08:09 -0800, Carl Worth wrote:
> 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?

It is a count of the total drawn within one minute. Widgets are
constantly being invalidated by calling gtk_widget_queue_draw() in an
idle, and the test is quit after 60 seconds have passed. 

The source is here:
http://folks.o-hand.com/jorn/cairo-benchmarks/timewidgets.c

> 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).

The expose time number is unreliable and is there merely because I
haven't bothered to either improve or remove it (I should have, though-
will do for following runs). There are several reasons for its 
unreliability:

o It is an arithmetic mean. To get a proper number one would need to
  weed out any outliers before taking the mean. 

o The time is taken as the interval between the calling of a signal
  handler before the widget handles its expose event, and the calling
  of a signal afterward. This does not take GSignal overhead into
  account.

o The tests use the return value of g_timer_elapsed(), which is a
  double. This may in some cases be (slightly) inaccurate.

The only numbers we should really be looking at here are the draw
counts.

> 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.

Between runs, the draw count sees a mean absolute deviation of
approximately 20.

> 
> > 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").

Yea, but the sample count analysis I brought in in my last mail should
also confirm things without using any percentages.

> 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.

Ok.

> > 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.

Sounds promising. :)

> 
> > > 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.

As gettimeofday() only has a centisecond granularity on this ARM here,
cairo-perf isn't being very helpful. However I attach a simple perf case
that should (although I can't verify) illustrate the problem.

> 
> > 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?

1.3.8 sees a 1.15x text drawing speedup wrt 1.3.6 (which performs about
the same as 1.2.4) -- probably due to Behdad's show_glyphs rework. With
1.3.10 text drawing sees a 0.89x slowdown. I'll trace down what exactly
causes this (hopefully) tomorrow.

Thanks,

Jorn


-- 
OpenedHand Ltd.
http://o-hand.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rectangle-perf-test.patch
Type: text/x-patch
Size: 3428 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070130/60ca3ba7/rectangle-perf-test.bin