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



On Fri, 2003-06-13 at 10:08, Michael Meeks wrote:
> Hi Rodrigo,
> 
> On Thu, 2003-06-12 at 21:57, Rodrigo Moya wrote:
> > 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.
> 
> 	Right; surely propagating more semantic information such as:
> 
> Foo getAllEventsInDateRange (in DateTime start, in DateTime end);
> 
> 	would allow more scope for optimisation; presumably there is no need to
> get more data than can be viewed (at least at first ?).
> 
well, we already have the query object, which, via s-exp's, allows us to
do this sort of queries. In fact, ot is what we do, the problem is that
for each query, we call the get_uids method :-(

We should really avoid that step and just do the query and return the
objects we are querying for.

> > 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.
> 
> 	I suppose, from that trace it seems that there's little point in
> avoiding those CORBA calls, since they're not the slow thing; OTOH.
> caching may slow things down if done in the wrong place, add more code
> and make things slower [ memory footprint etc. ] ;-) but ...
> 
oh, it's not those calls that slow down things? Also, when I talk about
a cache on the client side, it just means to keep the query objects
(CORBA) around. Right now, we create them, get the results, and destroy
them, while the query object has the feature of being updated live.
Thus, if you keep them around, and need to ask for the same query
(needed if you go back and forward again in your calendar), you will
have all the query results already on the client, with any modification
that has been made in between, since the query object gets any update
live, while it's still alive.

This will avoid a lot of CORBA calls, and the only problem I can see is
the memory used by all the cached queries.

cheers




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]