To XCB or not to XCB ...
l.lunak at suse.cz
Wed Aug 30 05:04:02 PDT 2006
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
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.
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
More information about the xorg