[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] korganizer doesn't save resources immediately when
From:       "Jason 'vanRijn' Kasper" <vr () movingparts ! net>
Date:       2007-03-28 3:19:47
Message-ID: 200703272319.47689.vR () movingparts ! net
[Download RAW message or body]

Hi Mark,

MAN squirrelmail does ugly things to e-mail formatting!!  =:D

On Tuesday 27 March 2007 19:52:39 mark@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@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]