Re: Dispatch of GObject virtual functions in GtkMM

[Murray Cumming <murrayc murrayc com>]

On Sun, 2007-01-28 at 20:09 +0100, Daniel Elstner wrote:
> Am Sonntag, den 28.01.2007, 12:43 -0600 schrieb Matt Hoosier:
> 
> > Yeah, agreed. These are all non-custom widgets, so the
> > Glib::ObjectBase() constructor should be called with the 0 parameter
> > to indicate no fancy dispatch needs to happen.
> 
> Right.
> 
> > Maybe there's just so little actual work (usually, plop the child
> > widget inside a linked list and mark a size-negotiation queue request)
> > that the C++ call itself is a big fraction of the total execution.
> 
> Yes, this could be.  Some type conversions can be rather expensive, as
> e.g. objects of boxed type have to be copied in order to put them into
> the wrapper object, which involves memory allocation.  Even if no type
> conversion takes place, retrieving the wrapper instance from the GObject
> requires at least one hash table lookup.  reference() and unreference()
> are also a bit more expensive than they should be, since both are
> virtual (pointlessly so, in my opinion) and might even involve locking
> or atomic increment/decrement on the GObject side.
> 
> > On the other hand, for custom widgets: perhaps there's some way that
> > custom widgets can override the vfunc pointer in their GObject class
> > in exactly the same way that one does when overriding a method in
> > regular GObject? Would that break anything in gtkmm?
> 
> Well, if you subclass the GObject as you would in plain C without gtkmm,
> it's of course possible to wrap the result as a non-custom widget in
> gtkmm.  Is that what you meant?
> 
> > > Also, are you using code size optimization, which could make it slower?
> > > Are you building with exceptions?
> > 
> > Yes, I'm using -Os; exceptions are disabled.

-Os is optimization for code size rather than speed. Normal optimization
might make it faster.

> As a side note, I discovered that at least with GCC 4.1, -O3 actually
> produces smaller binaries than -O2 for my C++ programs on the amd64
> architecture.  This is probably in part due to automatic inlining of
> very small functions like Gtk::manage<>(), which would otherwise be
> replicated with identical content for each different template argument
> used.
> 
> In my opinion functions like Gtk::manage<>() should have been declared
> inline in the first place, but unfortunately we can't do that now
> without breaking ABI.  (Well, unless one uses some trickery to always
> include the definition of the inline function when compiling the library
> itself, but...)

Such ABI breaks are possible for the optional API used by embedded
devices. I believe that's what Matt is interested in.

But inlining could increase code size, so there may be a tradeoff choice
to make.

> On another unrelated side note, the way GCC implements exception
> handling there is absolutely no overhead in the generated code if no
> exception is actually thrown.  Apart from the code size increase, of
> course.  The exception handling paths are appended at the bottom of the
> function.

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