brainstorming for UDS-N - Performance

[Bryce Harrington]

On Mon, Oct 04, 2010 at 10:18:59AM -0700, Kees Cook wrote:
> > > Have a tool polling for x clients? Use kvm-autotest's screen content
> > > checker? There a lot of options, I think.
> > 
> > For gtk apps, gtk provides a routine to do a single iteration through
> > the main loop and then return.
> > 
> > http://www.mail-archive.com/gtg-contributors@lists.launchpad.net/msg00249.html
> > http://bazaar.launchpad.net/~gtg/gtg/trunk/revision/858
> > 
> > Not perfect (no guarantee the app is going to be fully initialized in
> > one main loop iteration), but at least gives a crude measure of the
> > initial initialization cost.
> 
> Wouldn't this require patching each Gtk application that we wanted to
> collect measurements from?

Yes

However, there's probably a finite number of gtk apps with noteworthy
startup problems.  For the rest, their startup time is likely going to
mainly be driven by I/O and gtk itself, so spot testing a handful would
probably get 80-90% of the benefit.

> I wonder if it would be easy to externally
> instrument runtime via gdb breakpoints or something to create the same
> behavior?

I'm doubtful it'd be easy, but you're the guru here.  Knowing you,
you've probably already got a proof of concept implemented!  :-)

However...

One benefit of this approach is that aside from getting a raw time on
the boot, you can also profile it and get a good idea of what functions
are taking up the most time.  Not sure if that'd be doable with a gdb
approach.

Also, if these patches were sent upstream it might help spur on upstream
work to improve startup times.  Especially if they knew we were tracking
it in graphs and so on.

Bryce