Version: 1.2.7 (using KDE 3.5.7, Debian Package 4:3.5.7.dfsg.1-1 (lenny/sid)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.21-1-686 powertop[1] is brining up all sorts of previously unknown issues with Linux power management. Of suprise to me was akregator, sitting idle in my task bar is using around 10%: 10.1% (10.6) akregator : schedule_timeout (process_timeout) This is with seven feeds fetching every 30 mins :-( aRts has gone through a similar exercise[2] [1] http://www.linuxpowertop.org/ [2] http://vir.homelinux.org/blog/index.php?url=archives/41-PowerTOP-and-aRts.html Could be worth a look under the hood of akregator. Mark
Seems to be related to the option: Mark selected article read after XX sec When XX is 0 (the default) interrupt usage is high, I guess it is constantly polling. When disabled, or set to non-zero interrupt usage is non-existant. Short term, the default should be changed to 1 sec (almost no difference in usage), long term the polling loop should be made a little smarter and not poll, but be event driven when the user goes to a new article. Mark
I tried to reproduce the bug (Debian unstable packages), but wasn't able to. ~30 feeds, marking as read after 0 seconds. Akregator only appears sometimes, with < 0,5 wake-ups/s. Could you please provide more details, e.g. what size does your archive have, do wake-ups increase over time, steps to reproduce?
> Short term, the default should be changed to 1 sec (almost no difference in usage) Of course there is a big difference in usage, when navigating through the articles with the cursor keys, the articles selected for < 1 sec are not marked read anymore. >, long term the polling loop should be made a little smarter and not poll, but > be event driven when the user goes to a new article. There is no polling needed for any related functionality in Akregator. But there might be a timer incorrectly set up, firing constantly instead of once. (the lower the n, the more frequent are the wakeups) I will investigate.
BTW. I use akregator and I see a constant ~0.5 wakeups/s. I've been using callgrind to track it down, by comparing call counts for akregator running for different amounts of time (using --nofork --hide-mainwindow). I've traced it to Akregator::Backend::StorageMK4Impl::slotCommit. I expect to post a separate bug with a patch. I thought it might help if I mentioned it. a) Fixing the lesser problem might make easier to isolate this bug. b) I can summarize the timers I found and dismissed; it's possible one of these is responsible for this bug. c) The same brute force I used might help find this bug. I'm using "valgrind --tool=callgrind akregator --nofork --hide-mainwindow", and kcachegrind to view the output. I isolated the ~0.5 wakeup/s issue by comparing the output for two akregators running for different lengths of time, and comparing call counts for the callees of QObject::activate_signal(QConnectionList*, QUObject*). (Against akregator 3.5.6-0ubuntu6) and checking the call count for the method called by the timer. First column is # of times the timer fired during a test run. "start/stop" means that the timer is not expected to run continually. 1 akregator_part.h:213: QTimer* m_autosaveTimer; // 5 minutes slotSaveFeedList() 1 akregator_view.h:328: QTimer *m_fetchTimer; // 1 minute slotDoIntervalFetches() 0 akregator_view.h:329: QTimer* m_expiryTimer; // 1 hour slotDeleteExpiredArticles() 0 akregator_view.h:330: QTimer *m_markReadTimer; // Settings::markReadDelay() seconds, start/stop, slotSetCurrentArticleReadDelayed() /* one-off (during startup) */ 1 akregator_view.cpp:369: QTimer::singleShot(1000, this, SLOT(slotDeleteExpiredArticles()) ); 1 / akregator_view.cpp:370: QTimer::singleShot(0, this, SLOT(delayedInit())); \ akregator_view.cpp:381: QTimer::singleShot(500, this, SLOT(delayedInit())); 0 feedlistview.cpp:70: QTimer autoopentimer; // 750ms, start/stop openFolder() 0 searchbar.cpp:57: QTimer timer; // 200ms, start/stop, slotActivateSearch() /* 2 seconds, start/stop, batches new article notifications when they come in */ 0 notificationmanager.cpp:70: QTimer::singleShot(m_checkInterval, this, SLOT(slotIntervalCheck())); 0 notificationmanager.cpp:126: QTimer::singleShot(m_checkInterval, this, SLOT(slotIntervalCheck()));
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.