GNOME Bugzilla – Bug 352170
A large queue slows everything down
Last modified: 2006-08-23 15:16:47 UTC
With 25k articles in queue everythign appears to be slow. Redrawing the window can take tens of seconds while Pan consumes all cpu. Downloading articles is very slow (the downloads progress slowly), and make Pan consume all cpu. But memory consumption is not bad :) Pan version 0.109.
I think you submitted the same bug 3 times ;) 352170, 352168, 352169 Can you consolidate them and then close the duplicates? Thanks!
Very well: inserting the 25k articles into queue takes 10 minutes on a fast machine. Pan also tends to make the X server consume a great deal of cpu, slowing down all other graphical programs in the system excessively, even if there aren't more than a few hundred articles in the queue (not sure how it works with a small queue). Basically, insert 25k articles into the queue, and if you don't find Pan completely uselessly slow after that, you're not repeating the problem the way I'm seeing it. All this on Ubuntu 6.06 (Dapper).
*** Bug 352169 has been marked as a duplicate of this bug. ***
*** Bug 352168 has been marked as a duplicate of this bug. ***
I can partially confirm this behavior, I added 1800 articles to the Queue from gmame.linux.kernel and it took almost 40 seconds so I can see where 25k would take a long time. I then deleted these items from the Queue and Pan was not responsive for ~2 minutes and 100% of my CPU was being used. I am not if this behavior is new since I have never added that many articles before.
The patch is too big to attach here, but for 0.110: * inserting 25k articles into the queue now takes three seconds, compiled without optimizations, on my four year old AMD budget box. * with 25k articles in the queue and 12 connections (3 servers x 4 per server) grinding away, Pan's averaging 15-30% CPU on the same budget box. * Tweaked away some small amount of memory overhead in Task object by converting a lot of std::set to Loki::AssocMaps. (i.e., for unchanging containers that need to be bsearched frequently, use a sorted array instead of a btree to avoid node/pointer/fragmentation overhead). Thanks for reporting this, Samuli. This is exactly the kind of performance that Pan needs to be able to brag about to show why the rewrite is better than 0.14.x. ;)
Impressive improvement indeed :) Tried to test this by compiling the CVS version, but the compilation failed with the first line of pan/xpm/pan-pixbufs.h being "const guint8 icon_article_new[] = ".
(In reply to comment #7) > Impressive improvement indeed :) > > Tried to test this by compiling the CVS version, but the compilation failed > with the first line of pan/xpm/pan-pixbufs.h being "const guint8 > icon_article_new[] = ". > The version in CVS is the old 0.14.90 and not the new Pre-1.0 branch. Charles has stated that he plans to return to using CVS at some point but I think the hectic pace of development has taken priority.