Re: [Evolution-hackers] evolution-1.4 method trace ...

[Ettore Perazzoli <ettore ximian com>]

Hi Michael,

thanks for looking into this.

On Wed, 2003-06-11 at 05:36, Michael Meeks wrote:
> 	Perhaps doing a one-time recursive cache lookup of:
> 
> 	/apps/evolution/summary/		x11
> 	/apps/evolution/shell/view_defaults/	x8
> 	/apps/evolution/mail/display/		x12
> 	/apps/evolution/calender/tasks/		x5
> 	/apps/evolution/calender/display/	x16
> 
> 	Would save ~50 round-trips to gconfd and presumably save a number of
> milliseconds on startup / view switch.
> 
> 	It's also easy to fix with a few:
> 
> 	gconf_client_add_dir (gconf_client_get_default (),
> 	                      "apps/evolution/summary",
> 	                      GCONF_CLIENT_PRELOAD_RECURSIVE,
> 	                      NULL);

What if we just add a similar thing, but for "/apps/evolution", in the
shell on startup?  Since all the modules are using the default
GConfClient, that should propagate to all of them?

Although maybe it's better to have a separate GConfClient per component
to make sure they don't react to a "value_changed" when they shouldn't.

> 	When the calendar starts doing things in the Log; we notice the string
> truncation in the trace [ which mercifully obscures most of my calendar
> data ;-], and we see a ~large number of serial synchronous:
> 
> 	GetObject (N); GetObject (N+1); etc.
> 
> 	calls which IMHO would be prime target for a GetObjects ({N, N+1}) type
> method. [ I was scrolling up and down my calendar there ], but even so
> one GetObject set was 5.064958 to 5.086564 = ~22ms - which wouldn't
> explain the really noticable delay with calendar scrolling - perhaps
> that's related more to idle / canvas effects [ assuming it uses the
> canvas ;-].

It does use canvas, I am not sure where the performance hit is since I
don't think we profiled this recently.

Any opinions from the calendar/addressbook people?

-- Ettore