Bug 49333

Summary:	extreme delay in knode when displaying article headers
Product:	knode	Reporter:	nwourms
Component:	general	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	deller, grundleborg
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:

Description nwourms 2002-10-18 14:35:08 UTC

Version: (using KDE Devel)
Installed from: Compiled sources
Compiler: gcc 3.2.1 (prerelease)
OS: Linux

I just strarted using knode to read my gmane mailing lists. I noticed, however, that it take an awefully long time for knode to load the article headers for high-volume lists. I did some tests with gmane.linux.kernel (~2400 headers) and found it took about 7 minutes for a pIII/800 (320MB ram) to display the headers. I know it isn't my machine because konqueror is quite fast. Since I just started using knode, I have no previous experience to benchmark it with, but this seems to be quite unacceptable as it happens every time I switch between groups.

To reproduce:
1) Compile all the latest kde-base/qt applications from CVS using gcc-3.2.
2) Point knode to news.gmane.org (anon access)
3) Subscribe to gmane.linux.kernel and a few other random groups.
4) Set the default to sort by thread and date, expanding all threads by default.
5) Switch between gmane.linux.kernel and other groups to see the symptoms I describe.

I don't think this is a corrupted cache issue because I have completely killed all my kde settings and /tmp files between compiles of cvs sources. the behaviour has remained consistant though.

While this isn't a showstopper, it is rather frustrating and lessens the enjoyment of kde. I'm willing to help debug, but I will need specifics on how to go about setting up profiling (which I've never done before) and how to collect the pertinent data.

Comment 1 Christian Gebauer 2002-11-04 03:26:53 UTC

yes, displaying the article list is very slow, when the "expanding all threads by default" 
option is enabled. As a quick workaround I would recommend you to deactivate 
the "expand all threads by default" option

Comment 2 Niels 2004-04-19 14:58:08 UTC

This is still a problem on Knode 0.7.7 (KDE 3.2.1).

gmane.linux.kernel has about 100000 articles, and Knode grinds to a halt when trying to open that group.

Comment 3 George Goldberg 2007-12-18 08:03:30 UTC

Is this bug still present in a recent version of KDE, such as 3.5.8 or KDE 4.0 RC 2?

Comment 4 Helge Deller 2009-03-24 22:27:26 UTC

I used latest knode version of KDE 3.5.x and there the bug was fixed.
Now after switching to KDE4, I can confirm that reading/scrolling high volume lists is nearly impossible with KNode Version 0.99.01 (KDE 4.2.1, Fedora 10).
Even on my dual-core Core2 Laptop, KNode consumes 100% CPU for long time.
In my opinion it's a major regression to KDE 3.5.
The "expand all threads by default" option has no effect on performance in KNode 0.99.1

Comment 5 Andrew Crouthamel 2018-09-04 18:37:03 UTC

Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug.