[Pan-users] Re: Pan has 8 Processes, using 1436MB! That's eatingmy RAM!

[Duncan]

Calin A. Culianu posted
<address@hidden>, excerpted
below,  on Fri, 28 May 2004 06:54:26 -0500:

> 
>> 
>> At present, I'm skeptical on the memory leak issue, and am thinking 
>> that it's simply the amount of headers  available that's causing pan 
>> to go wild. I've seen the consumption decrease, if, for instance I 
> 
> Other newsreading programs (say, Newsgrabber on Windows) don't react quite 
> so badly to so many headers.
> 
> Pan definitely needs to be fixed to handle large numbers of headers.  It 
> is definitely a solvable problem and the proof is other newsreaders cope 
> better with this situation..

I believe the problem isn't with PAN itself, but rather with the GTK
widgets it uses.  These were designed as graphical widgets, not as
database processing widgets, so tho they can be used for that, they aren't
all that efficient at it.  PAN has had this problem for some time and is
actually far better than it used to be, having coded around some of the
worst performance issues related to the widgets.  However, it's admittedly
a less than optimal solution.

PAN is supposed to at some point switch to a database library backend,
probably sqlite.  A couple months ago there was a bit of discussion on the
devel list about this very thing, and a potential volunteer to help with
it, that knew something about working with databases.  Charles has seemed
a bit hesitant to get into it, I'm guessing because that isn't his area of
expertise, but remarked in the exchange there that now was a pretty good
time to do it since PAN had stabilized at its current level and he
(Charles) didn't have a lot of time to work on it much, right now, so the
code base would be pretty stable if this volunteer did indeed want to run
with it.  After a few messages, however, I believe they took the exchange
to private e-mail, and I haven't read anything about it since.  I don't
know whether that volunteer decided it was more than he wanted to get
into, or whether the project is going fine but is just complex, or whether
it's basically done and waiting for Charles to get time to integrate it
back into the main code base for a new beta.  It's possible, however, that
those using CVS builds (I've stuck with beta releases, so far) may know a
bit more.

Anyway, when that switch to sqlite (or whatever) occurs, it will open up
whole new avenues of possibilities for PAN, potentially allowing fully
automated multi-server handling (where one now has to switch to each
server and queue downloads separately), and all sorts of other fancy
features, as well as dramatic performance increases due to moving off of
using those primarily graphical widgets for database handling.  Until
then, however, we are somewhat limited in the improvements that can be
made, particularly since any additional gains in the area of performance
and resource usage are likely to be rather difficult, and largely wasted
work, once that switch DOES occur.

Unfortunately, that switch could be just around the corner, or it could be
a year or longer from now, depending on what the volunteer status is, and
whether Charles continues to be so busy with meat-space stuff that he has
little time for PAN coding.  (Of course, much of that has to do with the
fact that PAN doesn't pay him much, tho there's a paypal donate button on
the site or was last I looked, while the job taking his time now, does. 
If someone with the money were to sponsor PAN development...)  It's also
possible that Charles will NEVER get that sort of time again, and the
project will remain virtually static unless someone else picks up the
pieces and begins active development again.  After all, PAN originated
with a different author,  according to the credits, and Charles took over
from him when he could no longer be as active as he once was, and the same
has happened to many other open source projects, so..

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin