Bug 170250

Summary:	akregator performance is horribly slow
Product:	[Applications] akregator	Reporter:	Neal Becker <ndbecker2>
Component:	general	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	ehabkost
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:

Description Neal Becker 2008-09-02 13:47:09 UTC

Version:           1.2.50 (using 4.1.00 (KDE 4.1.0), 4.1.0-3.fc9 Fedora)
Compiler:          gcc
OS:                Linux (x86_64) release 2.6.25.14-108.fc9.x86_64

I've used akgregator for many years, and it's been great.  Since kde3.5 -> kde4 update, it's horrible.  Click on a feed, and it may take a minute for any update to the screen, while cpu runs 100%.

Almost unusable.

Comment 1 Eduardo Habkost 2008-09-02 14:49:46 UTC

It looks like the problem I've reported on bug #170156. How big is your feed history archive?

Comment 2 Neal Becker 2008-09-02 15:27:07 UTC

Dunno, how do I tell (which file is it?)

Comment 3 Eduardo Habkost 2008-09-02 15:43:51 UTC

(In reply to comment #2)
> Dunno, how do I tell (which file is it?)
> 

How many years of articles are shown on each feed? Do you have all old articles archived since you started using Akregator?

You can check the size of ~/.kde/share/apps/akregator/Archive/, also.

If you have lots of archived articles like me (my akregator/Archive dir has 240MB), you probably had the same problem I have seen. If not, then it may be a different problem.

Comment 4 Neal Becker 2008-09-02 15:55:11 UTC

I mv'd Archive dir, and restarted.  Problem seems to be fixed.

I had not ever set any archive options.  I'm selecting 'expire after 60 days'.  Strangely (another bug?), none of the different options were selected.

Keep important articles is checked, although I've never used it (don't even know what defines and 'important' article).

Comment 5 Eduardo Habkost 2008-09-04 04:44:44 UTC

I will mark this bug as duplicate of bug #170156, as it was solved when your (multi-year like mine, I suppose) archive was removed, so it seems to be the totalCount() performance problem.

*** This bug has been marked as a duplicate of bug 170156 ***