glib vs. no-glib

**new_website85** · 30th December 2006, 07:52

Is there a performance advantage/disadvantage using Qt compiled with glib support? From the Trolltech docs:

"To enable closer integration with the GNOME deskop environment and tools, Qt 4.2 now contains support for the Glib eventloop. This makes it possible for Qt applications to use plugins made using other Glib-based frameworks, and even enables Qt plugins to be created for use with non-Qt applications."

I really don't care about closer integration with GNOME - I would like to develop pure Qt applications and would like a highly optimized Qt.

Also, Glib has been ported natively to Windows (using mingw) and to Mac OS X as well. Is there a reason why Trolltech only decided to add glib support to X11/Unix versions?

**e8johan** · 30th December 2006, 13:17

Regarding the porting of GLib - on Windows and OS X native event loops are used by Qt. The whole point of Qt and of the GLib integration is that Qt helps with portability. This means that Qt should be useful for developing for both KDE and Gnome - even if KDE is built using Qt.

**Brandybuck** · 30th December 2006, 19:08

Anyone know why Qt now uses the Glib event loop by default? I turn it off when I build, but I wonder why the Trolls thought it was better than their own.

**new_website85** · 31st December 2006, 00:23

Originally Posted by e8johan

Regarding the porting of GLib - on Windows and OS X native event loops are used by Qt. The whole point of Qt and of the GLib integration is that Qt helps with portability. This means that Qt should be useful for developing for both KDE and Gnome - even if KDE is built using Qt.

Most major GNOME/Gtk programs (Gimp, gaim, dia, gnumeric, abiword, etc.) have been ported natively to Windows and Mac OS X. I would think that including glib support on these platforms would give these developers the same advantages that the UNIX/X11 version now has.

More info: http://www.qtnode.net/wiki/GLib_Event_Loop

Glib is a pretty feature rich library with some nice data structures, threading support, and of course the event loop. But most (if not all) of this functionality is provided by Qt itself. And if Qt's implementation of the event loop is more performant, I'd rather disable glib support.

**wysota** · 31st December 2006, 08:54

An article on QDevBlog can shed a little light on the subject.

**new_website85** · 31st December 2006, 11:12

Originally Posted by wysota

An article on QDevBlog can shed a little light on the subject.

Yeah, I read that blog. Unfortunately, it doesn't cover performance. I've googled a bit, and haven't found anything. Since, it hasn't been brought up and people aren't really posting about performance increase/decrease, I'm assuming for now that it is a negligible change in performance. I find this strange, however, because one would think that using a new implementation of something as low level as the eventloop (which accounts for a large percentage of execution time) would definitely change performance one way or another.... The only performance factor I can come up with is the dynamic linker loading the additional libglib.{so,dylib,dll} (if it hasn't been loaded anyways) at program startup - this is of course negligible especially since glib is a relatively small library.

**wysota** · 2nd January 2007, 15:21

I think the performance change is not significant as both approaches surely try to optimise the thing. Glib is probably a bit slower as it has more features, but has more capabilities and probably proves to be better when multiple apps/libs use it. I don't know how the event loop in Glib works, is it shared between different apps or does every app have a separate instance of the loop?