Bug 100119 - periodic freezes (due to invisible background fetch of feeds?)
Summary: periodic freezes (due to invisible background fetch of feeds?)
Status: RESOLVED FIXED
Alias: None
Product: akregator
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-23 21:48 UTC by kris
Modified: 2005-06-09 00:19 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kris 2005-02-23 21:48:18 UTC
Version:           1.0 beta10 (using KDE 3.4.0 Level "a" , SUSE 9.2 UNSUPPORTED)
Compiler:          gcc version 3.3.4 (pre 3.3.5 20040809)
OS:                Linux (i686) release 2.6.8-24.11-default

akregator for KDE 3.3 worked fine and quickly.

The current akregator 3.4 beta doesn't. It periodically freezes, especially when clicking on folders that contain many feeds or many unread messages. After half a minute or so (Athlon XP2500+ with 1 GB RAM) the application recovers. CPU is 100% loaded during this time.

It looks as if there is a highly inefficient sort going on or if there is some background fetching of feeds going on that is not being visualized.
Comment 1 jonas 2005-05-13 01:59:05 UTC
I have the same experience with akregator 1.0.1 (KDE 3.3.2).
Comment 2 Bjarne Wichmann Petersen 2005-06-03 16:54:20 UTC
A "Me Too" here (Akregator 1.0 on kde 3.4 on FreeBSD 5-STABLE)

It is especially bad when the "All feeds"-folder is open and Akregator is fetching new feeds. Bangs the CPU to the roof, Akregator is unresponsive. And this goes on for several minutes.
Comment 3 Konrad Miller 2005-06-03 18:10:27 UTC
Same here on KDE 3.4.0, Akgregator 1.0, Linux 2.6.11.
Comment 4 Konrad Miller 2005-06-03 18:11:37 UTC
*** This bug has been confirmed by popular vote. ***
Comment 5 Frank Osterfeld 2005-06-04 01:51:53 UTC
When "All feeds" (or any folder with many subfeeds) is selected and the interval fetch starts, every feed fetched causes an update of the articlelist. Considering that even a single update can take a lot of time when the list contains many articles, Akregator goes totally bonkers when there are twenty updates in a row.
We need some mechanism to prevent these complete updates. Either by stopping the ongoing update when a new update request arrives (only possible with threads i think), or by delaying updates, so that multiple requests result in only one update. But well, both methods make it harder to keep data and views in sync, so we would have a lot of potential bugs here...

The article list needs optimization in general. The problem is, the optimization made for KDE 3.x is obsolete when migrating to KDE4, as the list view classes are completely different in Qt4.
Comment 6 Frank Osterfeld 2005-06-09 00:19:43 UTC
SVN commit 423578 by osterfeld:

Let's break everything: Instead of using one signal "signalChanged" to notify all updates, it's now splitted into signalChanged 
(actual node updates like title, unread count, icon...) and signalArticleAdded/Updated/Removed to notify changes in the article list.
This more fine-grained notification avoids complete updates of the ArticleListView just because some articles were added, removed or 
updated. So it's possible to select "All Feeds" now without freezing Akregator.
BUG: 100119 


 M  +5 -5      article.cpp  
 M  +76 -14    articlelistview.cpp  
 M  +9 -1      articlelistview.h  
 M  +26 -2     articleviewer.cpp  
 M  +6 -0      articleviewer.h  
 M  +36 -41    feed.cpp  
 M  +3 -4      feed.h  
 M  +0 -5      feedlist.cpp  
 M  +0 -8      feedlist.h  
 M  +30 -20    folder.cpp  
 M  +1 -1      folder.h  
 M  +26 -10    treenode.cpp  
 M  +25 -15    treenode.h