Re: Dispatch of GObject virtual functions in GtkMM

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

On 1/28/07, Murray Cumming <murrayc murrayc com> wrote:
> On Sun, 2007-01-28 at 11:17 -0600, Matt Hoosier wrote:
> [snip]
> > So here I think my original claim (that default signal handlers almost
> > double [.452 ~= 2 * .272] the time to perform method calls on the
> > widgets). The phase that I'm most interested in was the time to
> > instantiate widgets and add them into the parents. Removing the
> > default signal handlers helped matters a little: the overhead dropped
> > by .8 sec, but it's still significantly higher than the equivalent
> > Gtk+ vfunc calls by a full sec (.272 vs. .371).
>
> Yet gtkmm can't now be adding anything else than the C++ function call
> and maybe some parameter type conversions. Can you imagine any way that
> it could be faster?

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.

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.

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?

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

> Have you tried using kcachegrind or similar to find out exactly where
> the time is spent?

Not yet. I wanted to confirm that there's a slowdown before trying to
figure out a way to run various *grind tools natively on ARM. I wonder
whether oprofile would give good enough resolution to find the
hotspots,

> > I don't want to belabor things too much, but it might also be worth
> > nothing that Gtk+ on _this_ (isolated, not perhaps very
> > representative) test case is close to the magical 200 ms threshold
> > which is generally regarded as the "tolerable" delay in UI's.
> > Calibrating things as a delta from that point, gtkmm method dispatch
> > can impose significant perceptible delay.
> >
> > I'm re-attaching the sources to the program used to generate the
> > metric above. Murray: to answer your earlier confusion about callling
> > "gtk_main_quit()" inside the expose handlers, I did this just to
> > automate the closing of the window. None of the timing information
> > after first on-screen appearance is relevant for this test.
>
> --
> Murray Cumming
> murrayc murrayc com
> www.murrayc.com
> www.openismus.com