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

[Rodrigo Moya <rodrigo ximian com>]

On Thu, 2003-06-12 at 19:17, Ettore Perazzoli wrote:
> > 	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.
> > 
this is due to calling get_uids and then get_object for each UID. This
is how the calendar works and one thing I think should be removed (the
get_uids call, which forces backends to load all objects at startup,
making it too slow for things like connector.

I guess the calendar clients should just retrieve the objects they need
to, which, in the case of the UI is nothing more than the ones in the
time range being displayed. For things like the conduits, we can still
provide a call to get all UIDS, but the GUI should not rely on this.

> > 	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?
> 
yes, one of the things I wanted to do was to do the query cache I added
to the wombat to be in the client. Thus, queries would be loaded once,
updated live, and re-used by all clients. I guess this should avoid a
lot of CORBA calls.

cheers