[Kde-pim] korganizer doesn't save resources immediately when changed or deleted (bug 143511)

[Jason 'vanRijn' Kasper]

To my understanding after talking with Reinhold yesterday, it's not the disk 
activity that is expensive, it's the reparsing that happens inside libkcal as 
the library has to compute durations, offsets, recurrences, etc.  I still 
maintain, though, that this is preferred over data loss and saving on UD 
would be consistent with saving on C.

On Wednesday 28 March 2007 06:46:15 Jiri Navratil wrote:
> Hi,
>
> What about default usage of one file per event instead of one big file for
> everything (like maildir versus mbox) Then update / delete can be performed
> without troubles with performance.
>
> Best regards,
> Jiri Navratil
>
> 2007/3/28, Jason 'vanRijn' Kasper <vr at movingparts.net>:
> > Hi Mark,
> >
> > MAN squirrelmail does ugly things to e-mail formatting!!  =:D
> >
> > On Tuesday 27 March 2007 19:52:39 mark at easymailings.com wrote:
> > > > Re, fellow PIMsters...
> > > >
> > > > I suggest that we fix this problem by changing korganizer back to
> > >
> > > saving
> > >
> > > > its
> > > >
> > > > resource file (and living with the subsequent reload/reparse) on
> > >
> > > _every_
> > >
> > > > create, update, or delete action.  Kaddressbook does this, and while
> > >
> > > it
> > >
> > > > doesn't have nearly the work in the reload/reparse cycle, making
> > > >
> > > > korganizer
> > > >
> > > > behave the same way would be much more intuitive to our users, and
> > >
> > > would
> > >
> > > > also
> > > >
> > > > stop the data loss problems that are associated with not doing so.
> > >
> > > +1
> >
> > Thanks.  =:)
> >
> > > > I'd greatly appreciate some
> > > >
> > > > comments/concerns/discussion around this
> > >
> > > Do some simple profiling to figure out why the heck it takes so long to
> > > load a text file from disk. It shouldn't take long to narrow things
> > > down.
> >
> > I don't actually observe this on my system at all.  If I touch
> > ~/.kde/share/apps/korganizer/std.ics, it triggers the reload/reparse
> > process
> > and for me that happens in the blink of an eye.  I was hoping to get some
> > hard numbers from someone saying that it's been measured, but my guess is
> > that it's a subjective thing that depends greatly on the size of the
> > user's
> > calendar and the number of processes running that incur that overhead via
> > libkcal whenever a save happens.
> >
> > > This should be an extremely fast operation. A quick google shows
> > > examples of disk access speeds that are 40 MB/sec, and that doesn't
> >
> > count
> >
> > > the benefits of caching by the OS. It ain't disk I/O that's
> > > constraining this process ...
> >
> > *nod*
> >
> > > My guess is there are _lots_ of "news" and "deletes"
> > > inside loops.
> > >
> > >
> > >
> > > If this guess is correct, then you could allocate one pool of Incident
> > > objects at app startup that the resource framework draws from and
> > > replenishes as it processes the file.
> >
> > Well, my first concern is that we fix the data loss problem.  If it is
> > observed after that that we have a slowdown problem due to the
> > reload/reparsing that happens when korganizer saves its file (after every
> > CUD), then we should address it after problem #1 is fixed, imho.
> >
> >
> > --
> > -[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-
> > -[ KDE PIM Developer         //  http://www.kde.org  ]-
> > -[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-
> > _______________________________________________
> > kde-pim mailing list
> > kde-pim at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-pim
> > kde-pim home page at http://pim.kde.org/



-- 
 -[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-
 -[ KDE PIM Developer         //  http://www.kde.org  ]-
 -[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/