Re: Dispatch of GObject virtual functions in GtkMM

["Matt Hoosier" <matt hoosier gmail com>]

On 1/10/07, Murray Cumming <murrayc murrayc com> wrote:
> 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.

I don't wish to provoke a flame contest here, but I would simply say
that my experience is otherwise.

Creating pixbufs--or even deeply-nested widget structures--during
widget constructors [or any time before the first expose-event] on an
underpowered embedded CPU just takes a while. We're talking ~100
milliseconds. Twice that is even longer yet :)

> >  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.

If it turns out that this make a difference, would I be forgoing the
ability to do useful overriding of things like expose-event handlers?

Thanks, Murray.

--Matt