[Xcb] GTK-XCB is in progress(Profiling gtk-xcb vs gtk-x11)

[Jamey Sharp]

On Wed, Nov 08, 2006 at 05:25:00PM +0800, Yang JianJun wrote:
> I choose oprofile to test gtkperf for performance profiling.

Perfect! But I notice you compiled XCB with optimization turned off.
This may not be entirely fair. :-)

> I haven't test whether gdk-xcb is issuing more requests than the gdk-x11.

That would be good to check, you're right. From your results I suspect
it's not making much difference though.

> Just according to the total result time from gtkperf, gdk-xcb backend is a
> bit slower.

As others have said, reducing Xlib's output queue size will probably
make the numbers pretty comparable, and they're already quite close.

We could then talk about whether XCB's default output queue size should
be increased. The question comes down to whether normal X applications
should be optimized for throughput or latency. XCB currently picks
latency, but performance tests generally are testing only throughput. I
would love to hear informed arguments either way.

> Why I use xcb_no_operation in gdk-xcb:
> gdk-x11 maintain a window queue for windowing redraw. Each queue item has a
> serial, just the X request serial, which come from the NextRequest macro.

This approach isn't thread-safe, which is why XCB's API is designed to
discourage it. There may be various reasons why thread-safety doesn't
matter at these points in Gdk, but the right approach isn't generally
that hard. Since every XCB request returns its sequence number, ideally
you would use the sequence number of the request you're actually about
to issue. [1] That's difficult in gdkgeometry-x11.c, though.

So Gtk+ hackers, why can't gdk_window_queue just iterate the event queue
until the translate_queue drops below the desired size limit? That would
eliminate a bunch of code as well as the need to use NextRequest. :-)

> Maybe this brings down the gdk-xcb's performance? Should I avoid
> using xcb_no_operation as much as possible?

Generally, yes, because it doesn't do anything and this way of getting
the sequence number is ugly. :-) But it shouldn't have substantial
impact on performance here, I think. (No, Ross, it isn't a round-trip:
the NoOperation request has no reply.)

> "This design choice causes XCBNoOperation to be something like a factor of
> four times slower than XNoOperation in the current implementation. Note that
> NoOperation, a completely useless request, suffers the most...", Jamey said
> (How XCB's design affects its performance, solair.livejournal.com). Is it
> still right now?

Yes, it is. I didn't expect anybody to start using NoOperation, so I
didn't worry about it. :-)

Note that "four times slower" is still very, very fast in absolute
terms. It's only putting four bytes in the output queue, after all. And
we know how to make NoOperation go faster if anybody really cares. :-)

--Jamey

[1] Looking through the calls to NextRequest in Gdk, that's quite easy
in several cases. For example, gdk_selection_owner_set_for_display in
gdkselection-x11.c contains essentially these two lines (ignoring
conditionals and such):

	info->serial = NextRequest (GDK_WINDOW_XDISPLAY (owner));
	...
	XSetSelectionOwner (xdisplay, xselection, xwindow, time);

With XCB, it could look more like this:

	xcb_void_cookie_t serial;
	...
	serial = xcb_set_selection_owner (c, xwindow, xselection, time);
	...
	info->serial = serial.sequence;

All but two of the calls to NextRequest can be refactored this way
pretty trivially, I think. (I haven't had a chance to look at your code
yet; maybe you've already done this.) The remaining two are related to
the window translation queue you mentioned. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20061109/2bb6daf2/attachment.pgp