korganizer uses 100% CPU when enabling ical resource, and the UI is frozen until it finishes loading the file. It's an .ics file with a TODO list, not calendar events (although some TODOs have dates associated with them). I don't know if that makes any difference. Here are the contents of the file: hactar·⚡ grep BEGIN:VEVENT tarefas.ics | wc -l 0 hactar·⚡ grep BEGIN:JOURNAL tarefas.ics | wc -l 0 hactar·⚡ grep BEGIN:TODO tarefas.ics | wc -l 0 hactar·⚡ grep BEGIN:VTODO tarefas.ics | wc -l 94 hactar·⚡ grep BEGIN:VCALENDAR tarefas.ics | wc -l 1 hactar·⚡ grep BEGIN:VTIMEZONE tarefas.ics | wc -l 1 hactar·⚡ grep BEGIN:STANDARD tarefas.ics | wc -l 3 hactar·⚡ grep BEGIN:DAYLIGHT tarefas.ics | wc -l 2 Reproducible: Always Steps to Reproduce: 1. In KOrganizer's list of calendars in the lower left corner, untick the calendar for the TODO list. 2. Now tick it again to enable it. Actual Results: The korganizer process uses 100% CPU and the UI is frozen for 30 seconds or so. Expected Results: Instantly enable the calendar (I don't expect this to be a computationaly expensive operation).
The same thing happens with another file with fewer elements: hactar·⚡ grep BEGIN:VEVENT tarefas.ics | wc -l 0 hactar·⚡ grep BEGIN:JOURNAL tarefas.ics | wc -l 0 hactar·⚡ grep BEGIN:TODO tarefas.ics | wc -l 0 hactar·⚡ grep BEGIN:VTODO tarefas.ics | wc -l 26 hactar·⚡ grep BEGIN:VCALENDAR tarefas.ics | wc -l 1 hactar·⚡ grep BEGIN:VTIMEZONE tarefas.ics | wc -l 0 hactar·⚡ grep BEGIN:STANDARD tarefas.ics | wc -l 0 hactar·⚡ grep BEGIN:DAYLIGHT tarefas.ics | wc -l 0 Both files are local, by the way.
Comment from GCI student: I use 4.14.2, too. I could not reproduce. Ubuntu 14.10 with KDE 4.14.1
Comment from GCI student: I made a mistake(KDE 4.14.2)
Can't reproduce here either, same version. How did you try to add that ressource?
Just right-click the calendar list and add a new calendar based on an ical file (ICal-Kalenderdatei). The strange thing is that the bug doesn't happen right after the calendar is added. I can disable and enable it quickly as expected. But after closing KOrganizer (or Kontact) and opening it again, then the bug manifests itself and from then on disabling and enabling the resource uses a lot of CPU. Another strange thing is that I can't reproduce this bug on a new user account in the same system. Even if I configure the other resources I have in my original account (e.g., calendars from Google Calendar and Facebook) so that the same calendars are used both on my original account and the new one, this bug doesn't happen on the new account. There, things work as expected. So there must be some cruft in my Korganizer and/or Akonadi configuration or data files that is making KOrganizer do a lot of unnecessary processing. I have this user account for several years already and .kde, .local, .config etc have been there for a long time. Any suggestions on how to further debug this problem?
I'm affected by bug #340143 so I have hundreds of identities. Maybe that's what causing Kontact to use so much CPU? Is that plausible?
I just confirmed that the CPU usage is caused by the high number of identities. I manually removed 1999 identities from ~/.kde/share/config/emailidentities and now korganizer has a good performance. People might have such a high number of identities because of bug 340143 or bug 310428. Because of this history of bugs which add an unreasonable number of identities, and because that has severe performance implications I suggest adding a sanity check to kmail/korganizer that checks if the user has tens of empty identities, all called "Unnamed" (and also the localized version of the string, I have hundreds of "Unnamed" and hundreds of "Unbennant" identities), and if so prompts the user asking if he wants them deleted.
I'd like to add that it's not just showing/hiding resources. Everytime you try to add or edit an event, or change the calendar view from monthly to weekly or vice versa, for instance, you get 100% CPU usage and frozen UI for several tens of seconds.
I fixed invalid identity. So it fixed in 14.12.2