[Xcb] Re: To XCB or not to XCB ...

[Lubos Lunak]

On Tuesday 29 August 2006 21:23, Jamey Sharp wrote:
> > Is this about the fact that XCB is split up into a large number of
> > ridiculously small libraries that'll no doubt make ld.so choke with any
> > somewhat larger application or is this something else?
>
> I wasn't commenting on that concern, but let's think about it.
>
> According to the evidence from the X Network Performance paper, modern X
> apps use about five X extensions. (There's a double-counting error in
> the text of the paper, which claims ten extensions, but the data show
> between 2 and 7 per app.) Since BIG-REQUESTS is built into libXCB, that
> means five XCB libraries per pure-XCB app.

 That paper seems to be 3 years old. I suggest you try ldd | grep X11 on a 
couple of your favourite modern apps. Don't forget that toolkits like to pull 
in more and more dependencies so they may very well link against all such 
libs one day.

> Furthermore, apps that
> don't use the 13 extensions in Xext won't be loading the code for them,
> and that code need not be stored on disk/flash/ROM if no installed app
> uses it.

 libXext is ~50kB here and that's next to nothing. And it's very likely less 
than 13 libraries together.

> In all sincerity, two questions: Will a worst-case extra two libraries
> be a problem for apps when they've been ported to XCB?

 No. But I suppose that's not the right question. How about changing it from 
the Xlib-vs-XCB case to XCB-vs-what-it-could-be case and making the question 
to be Is "clean design" worth the overhead of let's say 15 libraries? (Where 
by "clean design" you probably mean having separate checkouts for separate 
libraries instead of having separate toplevel subdirs for one library.)
 
> And shouldn't we be fixing ld.so instead of breaking clean library designs?

 Yeah, I'm pretty sure Drepper will suddenly listen exactly to you :(. 
Until  -Bdirect (or prelink using some of those principles, or whatever) 
comes into effect, ld.so time in many cases will grow almost linearly with 
the number of libraries used and you can check how much Drepper has to say 
about that (http://sourceware.org/ml/binutils/2005-10/msg00437.html, don't 
forget to check the only answer there pointing out that he's missing some 
very basic points).

 Not to mention that there's bound to be some overhead per every library, 
Federico's http://primates.ximian.com/~federico/news-2006-04.html#21 is 
probably good as an example here, with one point, namely that he's wrong in 
saying that those about 16M can be saved by adding const here and there - a 
considerable portion of that is overhead caused simply by using all those 
libraries.

 Okay, I admit this is not a question of life or death, those dozen libraries 
are not going to change _that_ much, but still, is it really a good idea to 
have a dozen separated tiny libraries doing almost nothing that are more or 
less bound to go together anyway because ... er, why?

> So I don't want to hear more abstract criticism until you really have
> something to complain about -- and at that point, we'll do our best to
> fix whatever issue you find.
>
> --Jamey

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz