After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 352170 - A large queue slows everything down
A large queue slows everything down
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
pre-1.0 betas
Other Linux
: High normal
: 1.0
Assigned To: Charles Kerr
Pan QA Team
: 352168 352169 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-08-20 19:38 UTC by Samuli Kärkkäinen
Modified: 2006-08-23 15:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Samuli Kärkkäinen 2006-08-20 19:38:25 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.
Comment 1 Darren Albers 2006-08-20 20:44:47 UTC
I think you submitted the same bug 3 times  ;)
352170, 352168, 352169

Can you consolidate them and then close the duplicates?

Thanks!
Comment 2 Samuli Kärkkäinen 2006-08-20 20:50:53 UTC
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).
Comment 3 Samuli Kärkkäinen 2006-08-20 20:51:28 UTC
*** Bug 352169 has been marked as a duplicate of this bug. ***
Comment 4 Samuli Kärkkäinen 2006-08-20 20:51:52 UTC
*** Bug 352168 has been marked as a duplicate of this bug. ***
Comment 5 Darren Albers 2006-08-20 21:02:12 UTC
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.
Comment 6 Charles Kerr 2006-08-22 19:34:23 UTC
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. ;)
Comment 7 Samuli Kärkkäinen 2006-08-23 03:21:54 UTC
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[] = ".
Comment 8 Darren Albers 2006-08-23 15:16:47 UTC
(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.