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.
Attachment:
signature.asc
Description: Digital signature