Version: 3.4.1-r1 (using KDE KDE 3.4.1) Installed from: Gentoo Packages Compiler: sys-devel/gcc-3.4.4 OS: Linux Linux Kernel: 2.6.12-rc1-ck1 (custom patch) How to Reproduce: Run akregator, run another application, it's terribly noticable. Expected Behaviour: Foreground processes should never notice. I noticed the other day while playing my game Enemy Territory it would lockup during play. Thinking this was a kernel problem I upgraded to the latest and the same problem. Then I noticed it while playing video with mplayer, so I keep mplayer going and run top. On my 2700+ Athlon it _locks_up_ my computer while updating. Usually for 2-6 seconds. The top output shows that akregator is the culprit. I'm not sure what can be done to fix it for sure, but it would be nice if it's possible to run at a lower priority(?) or maybe there's a fundamental problem here(?). I have about 20-30 feeds, and never delete archives. As a workaround for now I will attempt to start it only with the lowest nice priority and hope for the best, or just completely stop it when playing I/O intensive applications.
Do you have the root folder ("All Feeds") selected while updating? If so, this freezes Akregator badly and eats a lot of CPU. (On my box, only killing Akregator helped) The "All Feeds" problem should be improved in 3.4.2 and hopefully completely fixed in 3.5.
Yes, I do know what you're talking about here with it being in 'All Feeds' but I don't necessarily have it selected (it's usually just sitting in the tray, also).
This behavior is not only happening, when all feeds is selected. I have a lot of feeds in my akregator (maybe 200) and about 50.000 to 60.000 unread messages in there. This is happening of course with all this feeds, when starting akregator, finishing akregator (both even, if not selected "all feeds") and when akregator is updating the feeds. I played a little with this update funktions around. My CPU is 100% for a minute or two and all seems to freeze/run very very low. I can see in akregator, that it is updating all the feeds. When the update is finished, all runs normal (although akregator is eating a lot of RAM with this feeds, too). Maybe this updating should be done in "nice 19". If there is some idle time, do the updates. Maybe it helps also, to runn the feed-updates a little random or just one by one, not all at same time.
Could you test if selecting a feed with a small number of articles (or not selecting any feed at all, showing the about screen) makes a difference? Maybe we should do some profiling to find out what's eating the CPU. Whether it's caused by the actual fetching or by the processing in Akregator.
If I update my complete feed-list and click on a small feed (less than 100 unread news) or click on the about screen, it needs just a second or two. If I update the complete feed-list and click on a big feed list (more than 7000 unread news), i have to wait 10 seconds. If I do not update my feeds and click on the big feed list, it takes 8 seconds. This is every time the same, if I click again back to a small feed and then to a big feed list. Seems, that akregator processes the feed list every time again completely and this results in heavy latency and re-processing, which maybe can be prevented.
It's caused by the processing itself, rather than the fetching. I can see this happen even when I just Alt-Tab from another application to Akregator. Akregator should be lazily processing the entries. It already knows how many there are (it's displayed on the left) so it knows how long to make the scroll area. Each row could be initialised right before it needs to be displayed. I guess the remaining ones could also be done in a background thread to keep slightly ahead of the user.
This seems to have gotten ridiculously bad with the KDE 4.1 series of Kontact, verified with Kubuntu KDE 4.1 RC packages. I'm actually switching to Google Reader because I can't stand to wait 10-15 seconds for anything to happen.
*** This bug has been confirmed by popular vote. ***
*** Bug 209599 has been marked as a duplicate of this bug. ***
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of akregator (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.