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.
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
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.
Is this bug still present in a recent version of KDE, such as 3.5.8 or KDE 4.0 RC 2?
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
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug.