Re: Dispatch of GObject virtual functions in GtkMM

[Murray Cumming <murrayc murrayc com>]

On Wed, 2007-01-10 at 09:45 -0600, Matt Hoosier wrote:
> Hi,
> 
> I've been doing some benchmarking of basic little illustrative
> programs which record and print the time required to instantiate
> widget hierarchies of varying nesting depths. I write these programs
> first in regular Gtk+ and then with Gtkmm.
> 
> I consistently find that the time required to instantiate and add
> widgets into their parents is on the order of twice as expensive when
> done with Gtkmm.

I'd _expect_ that to be so quick that doubling it would still be
insignificant.

>  Is there significant overhead in the dispatch of
> GObject virtual functions? Am I right in visualizing the dispatch like
> this:
> 
>   * the thin custom GObject subclass of a label gets requested to expose
>   * the wrapper class tunnels this request out to overrideable virtual
> method on the C++ object
>   * the default implementation of the C++ method calls back down to
> the underlying GtkLabel C implementation

Yes, and in the case that it's just a Gtk::Label (not a deried MyLabel
class), there's not even any C->C++ parameter conversion. (grep for
is_derived_ in the .cc files to see the comments).

So that should just be a few quick function calls, though maybe the
GType introspection and dynamic_cast<> take some time. For instance,
there are lines such as this:

  CppObjectType *const obj = dynamic_cast<CppObjectType*>(
      Glib::ObjectBase::_get_current_wrapper((GObject*)self));

You might also try compiling glibmm and gtkmm with disabled vfuncs and
disabled default signal handlers to see if this makes much difference.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com