[Xcb] Question about xcb performance and threading support

[Benoît Minisini]

> Hi Benoît,
>
> At 1234876657 time_t, Benoît Minisini wrote:
> > I have currently using valgrind / callgrind & kcachegrind with the Gambas
> > IDE to try to understand why QT4.4 is slower than QT3.
> >
> > I noticed in the Gambas/QT4 kcachegrind output that pthread_mutex_lock
> > and pthread_mutex_unlock take respectively 1.41% and 1.52% of the
> > execution time.
> >
> > The Gambas/QT3 kcachegrind output gives approximatively the same result.
> >
> > I am a bit disappointed with that: using 3% of the total execution time
> > just to manage threads in a library for a completely non-threaded
> > application.
> >
> > Is there a way to optimize that? For example having a single-threaded
> > version of libxcb. Or is there something more complex behind that? (I
> > guess so...)
> >
> > My system is a Mandriva 2009 with libxcb 1.1.91.
>
> I might be wrong, but this can be related to the small size of the XCB
> buffer. I suggest you retry with libxcb >= 1.1.92 which has a bigger buffer
> by default (16k rather than 4k before).
>
> Cheers,

I am not sure.

Actually most of this time is taken by two functions from xcb-xlib: 
xcb_xlib_lock() and xcb_xlib_unlock().

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

So it seems that a lot of time is consumed in locking the display from the 
XLib.

Regards,

-- 
Benoît

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kcachegrind-xcb.png
Type: image/png
Size: 34475 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xcb/attachments/20090218/11421c03/attachment-0001.png