[Xcb] Question about xcb performance and threading support

Benoît Minisini gambas at users.sourceforge.net
Wed Feb 18 12:32:57 PST 2009


Hi,

First, thanks for your answer!

> In message <200902180002.26052.gambas at users.sourceforge.net> you wrote:
>
> Xlib and XCB are structured in such a way that
> pthread_mutex_lock() and pthread_mutex_unlock() should be
> no-ops if you use -lpthread-stubs instead of -lpthread in
> the compilation.  Thus, you could get rid of this overhead
> entirely by compiling QT4.4 in this fashion.  Of course,
> then the cool multi-threaded features of XCB would go away.

OK. I don't make threaded applications, so I'm not aware of such things. I 
don't compile QT4, I just use the one provided by the distribution where 
Gambas is installed. And the problem is the same with QT3 and GTK+.

>
> > Here is a screenshot from kcachegrind of the xcb/xcb-xlib
> > part of my test.
> >
> > Approximatively 2/3 of the _xcb_lock_io() and
> > _xcb_unlock_io() calls comes from xcb_xlib_lock() and
> > xcb_xlib_unlock(). The rest being the effective stuff
> > (xcb_send_request, xcb_poll_from_event...)
>
> Is QT4.4 compiled against the latest version of XCB with the
> handoff patches?  These may mostly eliminate this overhead.

I don't know. I just can tell that the libxcb Mandriva package version is 
1.1.91.

>
> > So it seems that a lot of time is consumed in locking the
> > display from the XLib.
>
> You should also be cautious about these profile results that
> are trying to capture the work percentage from 800K calls to
> small functions.  There's significant possibilities for
> sampling and accumulation error here.
>
> 	Bart

AFAIK, I think valgrind is accurate with function calls, because it "just" add 
CPU cycles taken by asm instructions and emulates the CPU instruction cache, 
the data cache, and the branch prediction unit. Not perfectly of course, but 
accurately.

Anyway, calling two functions a lot of times for nothing is not a good idea if 
it takes 3% CPU used by all X11 applications that won't use the threaded 
features of libxcb.

What is the purpose of the two functions in libX11: _XCBLockDisplay() and 
_XCBUnlockDisplay()? Are they here for allowing an application to use both 
libX11 and libxcb at the same time? Or for something else?

-- 
Benoît


More information about the Xcb mailing list