Re: [evolution-patches] patch for #70267 (calendar)

[Rodrigo Moya <rodrigo novell com>]

On Thu, 2004-12-09 at 09:15 -0500, JP Rosevear wrote:
> On Thu, 2004-12-09 at 01:15 +0100, Rodrigo Moya wrote:
> > 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
> 
> Sounds like we should just commit to 2.1.x then.
> 
committed to HEAD only then
-- 
Rodrigo Moya <rodrigo novell com>