Re: [evolution-patches] patch for #70267 (calendar)
- From: Rodrigo Moya <rodrigo novell com>
- To: JP Rosevear <jpr novell com>
- Cc: Evolution Patches <evolution-patches lists ximian com>
- Subject: Re: [evolution-patches] patch for #70267 (calendar)
- Date: Thu, 09 Dec 2004 01:15:07 +0100
On Wed, 2004-12-08 at 19:02 -0500, JP Rosevear wrote:
> On Thu, 2004-12-09 at 00:55 +0100, Rodrigo Moya wrote:
> > On Wed, 2004-12-08 at 15:52 -0500, JP Rosevear wrote:
> > > On Wed, 2004-12-08 at 12:00 +0100, Rodrigo Moya wrote:
> > > > On Wed, 2004-12-08 at 01:54 -0500, JP Rosevear wrote:
> > > > > On Tue, 2004-12-07 at 14:12 +0100, Rodrigo Moya wrote:
> > > > > > This patch adds 2 API calls to EFileCache to allow disabling temporarily
> > > > > > writing to disk, so that we can add/modify/remove a batch of objects and
> > > > > > do one write to disk for all changes instead of 1 per change.
> > > > > >
> > > > > > It is an API change, so not sure about 2.0.x, but it should be committed
> > > > > > there also, I guess. Maybe we could hide the 2 API calls in the header
> > > > > > file?
> > > > >
> > > > > Well, its just an addition right, so it won't break API or ABI
> > > > > compatibility (ie the existing code would work the same, saving
> > > > > everytime), right?
> > > > >
> > > > right
> > >
> > > So the only thing to do then is check the correctness and access the
> > > risk/reward. How much faster does it make something like the DVD
> > > calendar?
> > >
> > haven't seen much remarkable improvement, mainly due to the other speed
> > ups previously committed, but the number of writes to disk is reduced
> > from O(n^2) to only 1 write, at the end of the initial loading, so it
> > reduces the disk activity and hence should be much quicker for huge
> > calendars.
> >
> > Haven't been able to test with the DVD calendar, since for some reason,
> > it doesn't load, but this one
> > (webcal://ical.mac.com/wesley/Astronomy.ics) and this one
> > (webcal://ical.mac.com/ical/SoHo.ics), with several appointments per day
> > take 1 or 2 seconds maximum for loading.
>
> Before or after the fix?
>
after, usually it's 1 second or even less. Before it was more or less
the same, that's why I said there is no really remarkable improvement
for the user
--
Rodrigo Moya <rodrigo novell com>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]