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

List:       kde-pim
Subject:    Re: [Kde-pim] KOrganizer4 Is Sooo Slow
From:       "David Jarvie" <lists () astrojar ! org ! uk>
Date:       2007-11-05 15:37:41
Message-ID: 13224.S0VKQUNDQUo=.1194277061.squirrel () www ! sensical ! net
[Download RAW message or body]

On Monday 5 November 2007 14:26, David Faure wrote:
> On Monday 05 November 2007, Allen Winter wrote:
>> On Sunday 04 November 2007 20:51:16 Cornelius Schumacher wrote:
>> > On Monday 05 November 2007 02:38:33 Allen Winter wrote:
>> > >
>> > > Finally we know why KOrganizer is so slow.
>> > >
>> > > In CalendarLocal::rawEventsForDate:
>> > >       if ( event->dtStart() <= kdt ) {
>> > >         KDateTime end( event->dtEnd().toTimeSpec( event->dtStart() )
>> );
>> >
>> > The toTimeSpec call looks like it could spend a lot of time. Is this
>> actually
>> > the case?
>> >
>> > Why don't we convert the datetimes to UTC when saving the event?
>> >
>> > >         if ( event->allDay() ) {
>> > >           end.setDateOnly( true );
>> > >         } else {
>> > >           end = end.addSecs(-1);
>> > >         }
>> > >         if ( end >= kdt ) {
>> > >           eventList.append( event );
>> > >         }
>> >
>>
>>       //old code: much, much faster
>>       if ( event->dtStart().date() <= qd && event->dateEnd() >= qd ) {
>>         eventList.append( event );
>>       }
>>
>>       //new code: much, much slower
>>       if ( event->dtStart() <= kdt && event->dtEnd() >= kdt ) {
>>         eventList.append( event );
>>       }
>>       where, kdt = KDateTime(qt,timespec);
>
> So it's KDateTime::operator< which is slow? Or what does kcachegrind say?

If the time zones of the two values are the same in
KDateTime::operator<(), no time zone convesion is done, so there is no
overhead using KDateTime instead of QDateTime. If the time zones differ,
both values are converted to UTC first before comparing them. Since each
KDateTime value caches its UTC equivalent, there is only a conversion
overhead the first time the UTC value is calculated, for any given
KDateTime instance (or a direct copy of it - since data is implicitly
shared).

dtStart() always returns the start time stored in the event, so once it
has been converted to UTC, it will never need to be reconverted. dtEnd()
is similar when an end time is specified. What could give rise to
unnecessary calculations is when dtEnd() re-evaluates the end time every
time it is called, which occurs when the event has a duration. In this
case a fresh KDateTime instance will be created each time dtEnd() is
called, and it will have to be newly converted to UTC if that is required.

If KDateTime::operator<() actually does slow things down, the solution
would probably be to cache the dtEnd() value in KCal::Event. In fact, it
would be a good idea to cache all KDateTime values if they are likely to
be recalculated and produce the same result on consecutive calls.

-- 
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm

_______________________________________________
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]