[Pan-users] Re: Slow Responce, High Memory Usage

[Duncan]

Brian Morrison posted <address@hidden>,
excerpted below,  on Sun, 21 Aug 2005 22:42:36 +0100:

> On Sun, 21 Aug 2005 14:24:33 -0700 in
> address@hidden
> Klaus P Schreyack <address@hidden> wrote:
> 
>> Hi all,
>> 
>> I was wondering if anyone could elaborate as to why PAN consumes a huge
>> amount of memory when loading newsgroups >= 1 Million Headers ?
> 
> Because it is using a Gtk widget that was never designed to cope with
> such usage, a database backend is being developed to replace the current
> design but is not yet ready to integrate.

Exactly.  If you are the sort of person that likes compiling potentially
buggy software from CVS, PAN's CVS version has a number of improvements in
this area.  However, it's still quite CVS quality, at this point, with
several known instabilities and regressions to work thru, still (and I'm
not sure Charles is thru changing/adding features yet, either), before it
goes beta, let alone stable.

For very high traffic binary groups, particularly if you have access to
them on several servers, you may wish to check out klibido.  It's rather
younger than PAN, and doesn't have PAN's scoring and filtering, neither
does it handle text, but it certainly goes to down with the downloads, as
I said, particularly if you have multiple servers (and a high bandwidth
connection), and without the memory overhead of PAN.  Certain
distributions have packages for it (tho they might not be upto date), or
you can check out it's site @ sourceforge, http://klibido.sourceforge.net.

Or... check out BNR2/BNR3.  More mature than klibido, available for
MSWormOS or Linux, but not entirely open source, so it's not something I'd
run. (I don't know about the source itself, but it's compiled with the
Borland Delphi/Kylex slaveryware compiler.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html