Re: libeggdbus v. libdbus-glib

[Denys Vlasenko <vda linux googlemail com>]

On Thursday 17 September 2009 15:58, David Zeuthen wrote:
> On Thu, 2009-09-17 at 12:18 +0200, Denys Vlasenko wrote:
> > You wrote:
> > > * From: David Zeuthen <david fubar dk>
> > > * To: gtk-devel-list gnome org
> > > * Subject: EggDBus
> > > * Date: Sun, 21 Dec 2008 21:48:25 -0500
> > >
> > > Hey,
> > >
> > > For the past 5 weeks or so, I've been working on a new (as compared to
> > > dbus-glib) D-Bus binding for GObject. The work on this has finally
> > > reached a stage where the code sufficiently complete and documented so I
> > > thought I'd send some mail describing it. The code is here
> > 
> > > http://cgit.freedesktop.org/~david/eggdbus
> > 
> > Nine months later, some packages already started to use libeggdbus.
> > 
> > For example, PolicyKit. I got curious (or maybe "appalled") by the number
> > of libraries this "simple password prompter lib" pulls in,
> > so I looked at it.
> 
> If you think polkit is a "simple password prompter lib" you are really
> missing the point. The fact that (annoying and useless, I might add)
> passwords dialogs can be presented to interrupt the user is just a minor
> feature.
> 
> > Aside form much other stuff which is not relevant to this email,
> > it pulls in libeggdbus directly, and libdbus-glib indirectly:
> > 
> > # ldd /usr/lib64/libpolkit-gobject-1.so.0
> > ...
> > 	libeggdbus-1.so.0 => /usr/lib64/libeggdbus-1.so.0 (0x00007fbf5c314000)
> > ...
> > 	libdbus-glib-1.so.2 => /usr/lib64/libdbus-glib-1.so.2 (0x00007fbf5b3a1000)
> > ...
> > 
> > which made me wonder, how come a replacement for libdbus-glib
> > and libdbus-glib itself live in the same program. Ain't that
> > code duplication? 
> 
> Yes, EggDBus only uses the mainloop integration from dbus-glib. Yes,
> there's a reason for why this is so. Yes, the explanation is in the
> archives.
> 
> FWIW, I don't really know what the long term plan of D-Bus and the GLib
> stack is. You should ask the GLib maintainers. FWIW, I've been working
> on a new eggdbus-ish dbus library that is here
> 
> http://cgit.freedesktop.org/~david/gdbus-standalone
> 
> Unfortunately I haven't had a lot of time to work on this lately because
> other things are keeping me busy. Ideally we'd put this code in libgio
> and be done with it.
> 
> > So, your "new D-Bus binding for GObject" is making programs
> > use both at once anyway. Also, it is more than twice as big
> > as libdbus-glib just by itself:
> > 
> > # size /usr/lib64/libeggdbus-1.so.0
> >    text	   data	    bss	    dec	    hex	filename
> >  281912	  10776	    504	 293192	  47948	/usr/lib64/libeggdbus-1.so.0
> > 
> > # size /usr/lib64/libdbus-glib-1.so.2
> >    text	   data	    bss	    dec	    hex	filename
> >  128367	   4612	    328	 133307	  208bb	/usr/lib64/libdbus-glib-1.so.2
> > 
> > 
> > I do not know, maybe it presents some significantly nicer C interface
> > for the programmer, but on code size front it does not look good.
> > 
> > Sorry for intruding into your time and basically saying
> > that you write bloated code, but I wanted to make you aware
> > of this aspect too.
> 
> Listen, this "comparison" really makes no sense at all. You are counting
> bytes but don't bother to look at the interfaces?

Yes. I didn't plan to write a thesis about eternally
increasing sizes of software, I just semi-randomly
picked one library out of two dozens which the program
I work on links in. It so happens that it it your library.

I had two options:

(1) "sigh, how come we use link in megabytes of code,
    why on Earth our relatively simple task needs that much?..."
    and get on with my life,
    or
(2) Try to do at least something about it. Like looking into
    one of libraries and try to figure out at least the simplest,
    lowest hanging fruit to trim there, and talk to the author.
    After all, if I do absolutely nothing to fix it,
    how can I complain?

I took door #2.

To be honest, I did not have high hopes you'd be happy
to talk about it.

> You are counting
> bytes but don't bother to look at the interfaces?

I would look at the interfaces if I would need to use it
directly in my program. Thus far, I do not. I just use
polkit, which uses libeggdbus.

I looked into the code just now. I wanted to check, maybe
I'm really horribly wrong? Maybe it's a beautifully
tight, slim and efficient code after all?

This is an example I found in about 2 minutes:

src/eggdbus/eggdbusutils.c

egg_dbus_get_type_for_signature (const gchar *signature)
{
  GType type;

  type = G_TYPE_INVALID;

  if (strcmp (signature, DBUS_TYPE_STRING_AS_STRING) == 0)
    type = G_TYPE_STRING;
  else if (strcmp (signature, DBUS_TYPE_OBJECT_PATH_AS_STRING) == 0)
    type = EGG_DBUS_TYPE_OBJECT_PATH;
  else if (strcmp (signature, DBUS_TYPE_SIGNATURE_AS_STRING) == 0)
    type = EGG_DBUS_TYPE_SIGNATURE;
  else if (strcmp (signature, DBUS_TYPE_BYTE_AS_STRING) == 0)
    type = G_TYPE_UCHAR;
  else if (strcmp (signature, DBUS_TYPE_BOOLEAN_AS_STRING) == 0)
    type = G_TYPE_BOOLEAN;
  else if (strcmp (signature, DBUS_TYPE_INT16_AS_STRING) == 0)
    type = G_TYPE_INT;
  else if (strcmp (signature, DBUS_TYPE_UINT16_AS_STRING) == 0)
    type = G_TYPE_UINT;
  else if (strcmp (signature, DBUS_TYPE_INT32_AS_STRING) == 0)
    type = G_TYPE_INT;
  else if (strcmp (signature, DBUS_TYPE_UINT32_AS_STRING) == 0)
    type = G_TYPE_UINT;
  else if (strcmp (signature, DBUS_TYPE_INT64_AS_STRING) == 0)
    type = G_TYPE_INT64;
  else if (strcmp (signature, DBUS_TYPE_UINT64_AS_STRING) == 0)
    type = G_TYPE_UINT64;
  else if (strcmp (signature, DBUS_TYPE_DOUBLE_AS_STRING) == 0)
    type = G_TYPE_DOUBLE;
  else if (strcmp (signature, DBUS_TYPE_VARIANT_AS_STRING) == 0)
    type = EGG_DBUS_TYPE_VARIANT;
  else if (g_str_has_prefix (signature, DBUS_STRUCT_BEGIN_CHAR_AS_STRING))
    type = EGG_DBUS_TYPE_STRUCTURE;

These DBUS_TYPE_BYTE_AS_STRING are one-char strings.
You compare a dozen of them using strcmp. This is both slow
and bloaty.

--
vda