Re: GDBus in gio? [was Re: Minutes of the GTK+ Team Meeting - 2009-11-10]

[nf2 <nf2 email gmail com>]

On Tue, Nov 17, 2009 at 10:52 AM, Alexander Larsson <alexl redhat com> wrote:
> On Fri, 2009-11-13 at 16:37 +0200, Andrew W. Nosenko wrote:
>> On Fri, Nov 13, 2009 at 15:31, Alexander Larsson <alexl redhat com> wrote:
>> > On Fri, 2009-11-13 at 01:31 +0200, Andrew W. Nosenko wrote:
>> >> On Thu, Nov 12, 2009 at 20:52, Alexander Larsson <alexl redhat com> wrote:
>> >> > On Tue, 2009-11-10 at 18:22 -0600, Stef Walter wrote:
>> >> >> Emmanuele Bassi wrote:
>> >> >> > 1. bug 600141 (desrt)
>> >> >> > - dbus-1 brings in pthread
>> >> >> > - gio-2.0 doesn't
>> >> >> > - dlopen()-ing a shared object linking to pthread from a library
>> >> >> >   that doesn't is a big no-no which kind of works in Linux but
>> >> >> >   breaks things like gdb
>> >> >> > - big hammer: make gio-2.0 depend on gthread-2.0
>> >> >> > - small hammer: make gio-2.0 pkg-config file include -pthread
>> >> >> > ACTION: desrt should involve gtk-devel-list and gather feedback
>> >> >>
>> >> >> Is there a reason the dbus stuff won't become its own glib module along
>> >> >> side gio, gobject, gthread etc...?
>> >> >
>> >> > Well, gio would still need to link to this so all gio apps still pull it
>> >> > in. Additionally there is a non-negligible overhead for each library
>> >> > linked into an app (due to elf linking rules), so the extra library is a
>> >> > performance loss for all applications.
>> >>
>> >> Excuse me, but it is unclear about what you said: pthread or dbus?
>> >> I mean in the "Well, gio would still need to link to this so all gio
>> >> apps still pull it in" sentence.
>> >
>> > I meant to refer to gdbus by "it" here.
>>
>> Then yet another question: why do you think that all applications,
>> which linked with gio are need dbus and, therefore, would to be linked
>> with it anyway?
>>
>> Simple example: one of my programs uses libsoup.  Uses it for ages.
>> Just for HTTP server and, sometime, client.  Accordingly to your
>> logic, my program needs dbus and would be linked with it anyway.  Just
>> because since some version libsoup linked with libgio as dependency.
>>
>> But my program doesn't need dbus!  Moreover, I don't use even GIO directly!
>
> Yes, not all applications that link to gio needs every feature of gio.
> If you link to glib because you want to use GHashTable you get GRegexp
> for free, even if you don't want to use it. This will always be the case
> for libraries, unless we put one function in each library.
>
> Similarly there are (will be) features in libgio that require dbus (such
> as GVfs and a dconf based GSettings). Not all applications that use
> libgio will use these features of course, and the dependancy is
> redundant for those. However, the stuff we put in glib/gio are things
> that we deem a majority, or at least a large subset of applications will
> need (like settings and file i/o).
>
> So, since there are features in gio that require dbus it will need to
> pull in dbus, even if your app doesn't use that particular feature.
> However, if nothing uses the dbus using functionallity then most of
> libdbus will not have to be paged in. And anyway, since many apps use
> these things they are likely to be in memory anyway.
>
> Of course, there is the runtime linker overhead of the extra linked in
> library thats (in your case) not used, which is unfortunate. But this is
> still better than putting the dbus functionallity in its own module as
> then that overhead would be doubled (separate gdbus library + libdbus)
> for all apps that use dbus.
>

Hmm - i still wonder how many milliseconds putting everything into
libgio.so rather than having three separate libraries will really safe
you.

Looking up a symbol in a small library seems to be faster than in a
big one (the most important value is "unsuccessful lookup", as far as
I understand Ulrich Drepper's DSO Howto). Here are some numbers:

eu-readelf -I /usr/lib/libgobject-2.0.so

Average number of tests:   successful lookup: 1,192982
                          unsuccessful lookup: 0,507418

eu-readelf -I /usr/lib/libgmodule-2.0.so

 Average number of tests:   successful lookup: 1,170213
                          unsuccessful lookup: 0,540230

eu-readelf -I /usr/lib/libgio-2.0.so

 Average number of tests:   successful lookup: 1,355689
                          unsuccessful lookup: 0,818627

eu-readelf -I /usr/lib/libglib-2.0.so

Average number of tests:   successful lookup: 1,547899
                          unsuccessful lookup: 1,180556

eu-readelf -I /usr/lib/libgtk-x11-2.0.so.0

 Average number of tests:   successful lookup: 1,906439
                          unsuccessful lookup: 1,853385

Therefore I reckon when splitting relatively small libraries at the
basis, the increase in symbol lookup time will be less than linear.
And taking into account, that libgtk links about 50 libraries, the
impact of 5 more or less won't exceed 10%, which is far below the
psychological threshold of perception. So if you can't radically
reduce the number of libraries Gtk needs - from 50 to let's say 20 -
you won't feel any significant difference.

Furthermore, library binding is only a part of application startup
(IPC, configuration files ...), so we are more likely talking about
differences <3% of startup time. But thats just a guess.

For instance, what really made application startup faster on my
system, was disabling compiz. ;-)

Norbert


Btw, playing with this is quite interesting...

$ export LD_DEBUG=all
$ export LD_DEBUG_OUTPUT=lddebug.log
$ gedit