Re: Dispatch of GObject virtual functions in GtkMM

[Murray Cumming <murrayc murrayc com>]

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?

Also, are you using code size optimization, which could make it slower?
Are you building with exceptions?

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

> 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