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

[Jiri Navratil]

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/
>



-- 
Jiri Navratil, http://www.navratil.cz,  +420 777 224 245
_______________________________________________
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/