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
_______________________________________________
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution-hackers
