On Tue, 2008-08-19 at 18:51 +0200, Patrick Ohly wrote:
> On Sun, 2008-08-17 at 19:30 +0100, Ross Burton wrote:
> > On Sun, 2008-08-17 at 20:18 +0200, Patrick Ohly wrote:
> > > Do you plan to do that before replacing Bonobo in the mainline
> > > Evolution?
> >
> > Yes, finding out why getchanges() is so damn slow is on the list of
> > things to do.
>
> I'm afraid speeding up the underlying C implementation in the file back
> end will only delay the inevitable: as the number of contacts grows,
> there'll always be a point when the time out strikes too early. It's
> simply not possible to squeeze an O(n) (or worse) implementation into a
> fixed amount of time in all cases :-/
>
> Now in this case perhaps the implementation can be sped up so much that
> it doesn't matter. But in some other cases (backends which communicate
> with remote servers?) it will remain a problem.
>
> IMHO the underlying problem is that Bonobo/ORBit/CORBA allow calls which
> run for an unlimited amount of time whereas DBus doesn't. Therefore a
> simple mapping of CORBA calls to synchronous DBus calls will always be
> problematic.
>
> Do you think that mapping all synchronous libebook/libecal calls to
> asynchronous communication via DBus would be possible?
Any calls which can take longer than the DBus timeout and not be
considered to have a) serious implementation errors or b) timed out
remotely should be moved to method call -> signal pattern.
In the case of getChanges(), this is a local operation so just needs to
be fixed. It shouldn't take more than the timeout, even with 10k
contacts.
Ross
--
Ross Burton mail: ross burtonini com
jabber: ross burtonini com
www: http://burtonini.com
Attachment:
signature.asc
Description: This is a digitally signed message part