Version: (using KDE 4.0.98) Installed from: Compiled From Sources Compiler: gcc 4.1.2 OS: Linux Korganizer is _much_ slower than 3.5.x in the month view, especially going forward and backward between months. On my CoreDuo, it takes about 4 seconds to switch to the next month, no matter how many data there are in that month. This must be a bug somewhere. It is independent from OpenGL effects.
I experience the same problem, but also in day/week view. Updating the small calendar in the top left corner is also slow, takes several seconds to update on every change of view (the week view itself seems to update itself quicker, but still fairly slow). Building up the UI/view in general seems sluggish. When applying new settings from the configuration it slowly adds each resource (I have 9 calendars in remote files, webdav) before closing the settings dialog, taking about 2 seconds for each calendar (AMD Athlon64 3200+, running 32 bit Gentoo). Output gives a lot of "korganizer(10075)/kdepimlibs (kcal): Cannot read uid map file ' "/home/cheetah/.kdesvn/share/apps/kcal/uidmaps/remote_Akrz5V4gDY" ' " errors (the resource ID being different for each calendar), but nothing else. The uidmaps directory exists, but the requested files do not. Not sure if this is related. Not sure if it is a related issue, but I have a nVidia GeForce 6600GT (proprietary driver, 177.13), compositing (OpenGL) enabled. I haven't used any configuration tweaks to speed up nvidia performance yet.
It is definitely _not_ compositing related, as it happens also with compositing switched off. Moreover, I'm on intel and compositing is very smooth on my box.
I can confirm this with intel onboard chip and no compositing/desktop effects stuff on 4.1
Switching seems quicker again for me (trunk built last night). Seems to me like this bug is fixed.
Yes, we did commit some speedups yesterday which will be available in KDE 4.2 and KDE 4.1.1 I'm not closing this bug yet though because: 1) I still think the month view is too slow 2) there's more that can be sped up in the agenda view too
Better change it to 'NEW' if the bug is recognized.
In svn trunk r865619, going backwards and forwards in the month view still takes several seconds each time (no compositing, nvidia and intel graphics chips).
Does anyone who has slow switching see any warnings when running korganizer in a terminal. Warnings like these: korganizer(31354)/kdepimlibs (kcal) KCal::Event::dtEnd: Warning! Event ' "foo bar" ' has neither end date nor duration. I see hundreds of them every time i switch months, i guess its a faulty calendar file. I obtained it by exporting, in kde3
SVN commit 899875 by smartins: Don't call Calendar::events(KDateTime dt) for each day. Instead, call Calendar::events(KDateTime start, KDateTime end) just once. This takes care of performance problems in KODayMatrix::updateEvents(). CCBUG: 166771 M +40 -18 kodaymatrix.cpp M +2 -4 kodaymatrix.h WebSVN link: http://websvn.kde.org/?view=rev&revision=899875
SVN commit 900026 by smartins: Use Recurrence::timesInInterval() instead of Incidence->recursOn() for each day. Fixes performance problems with month switching. CCBUG: 166771 M +31 -7 monthview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=900026
Guys, If you're using korganizer from svn/trunk please update and give feedback, for me this is fixed.
Hi there, Although I have no time to test, I've got an idea how you could further speed things up: I implemented scrolling in the "old" monthview (it's somewhere in svn, but was never released as such because of the "new" monthview coming along). There, while scrolling, only the newly scrolled-in week(s) were updated instead of the whole month, because the other days are already up-to-date and simply were moved up/down. I don't know if it actually improved performance dramatically but it could definitely help a bit. But I think in the new monthview implementing this would be quite some work, because it's not really easy to move the contents of one day to another as there are several data structures concerned. Cheers, Thomas
Thanks for the help Thomas, I already got two others users to test this and they confirm it's fixed. I profiled the code and removed all bottlenecks. Switching months was taking 4 seconds, now it takes 40 milliseconds, so I think it's safe to close this one :)
*** Bug 180598 has been marked as a duplicate of this bug. ***