Re: [Pan-users] pan stops working/responding

[Duncan]

dchmelik-Re5JQEeQqe8AvxtiuMwx3w posted on Thu, 7 Sep 2023 00:20:07 -0700
as excerpted:

> If I select a high-activity group I haven't read before (such as
> gmane.linux.kernel which I guess is the mailing list and has hundreds
> thousands posts) pan soon stops working/responding.  I can no longer
> select any other group, nor any menu item, and if I cover or minimize
> pan and return later, it no longer even redraws its screen.  Today this
> has gone one for about six hours, which just to show one screen of
> posts, it shouldn't take this long!  I don't know why it'd have to
> prepare to show all posts from years ago because I probably won't look
> that far back.  Pan even stops responding like this if I mark that I've
> read all articles in the high-activity group and come back later,
> perhaps just to see the top page of articles.

Please verify the following preference is UNCHECKED:

Preferences > Behavior > Groups > Get new headers when entering group

(I keep Get new headers in subscribed groups on startup unchecked as well, 
for similar reasons, but if you're careful not to subscribe to groups that 
are too high volume that should be less of an issue, because unlike when 
you first enter a group, presumably pan has a memory of where you were in 
all your subscribed groups.)

Then, when grabbing your first headers, us the get headers ... dialog 
instead of getting new/all headers, and get the last N-days-worth or N-
hundred headers, thus restricting that initial header download.

After that, I'd suggest quick-changing groups out and back in, thus 
ensuring that pan stores where it was in the group (I got in this habit 
long ago, when pan wasn't as good about saving its current position and 
would lose track of read messages since the last time you switched groups 
if it crashed).

Then it should know where it was and getting "new" headers should only get 
new ones from there, so should be fine -- you won't have to restrict 
yourself to getting only N days or N count headers again unless you don't 
update for too long and it has too many new headers again.

The problem is that when you haven't visited the group before (or if pan 
crashed or froze and had to be killed while in the group before it finished 
loading headers), *ALL* messages are new.  Couple that with the fact that 
pan builds its threading model in memory (as opposed to a generally slower 
but much more memory-conservative model where it only has a few pages worth 
of header data in RAM at once and stores the rest in a file-based database 
of some sort, swapping back and forth between them as necessary to keep a 
low-memory working-set in RAM), AND gmane's archive-purposed lack of 
expiry, and high-volume groups/mailing-lists like the main linux kernel 
list are just too much.

(The same of course applies to the higher volume binary groups, even with a 
reasonable expiry there, but that's due to the many-individual-message-
segments-per-message and combined-header issue (in pan, where many such 
segments appear as a single combined header in its listing), which is a bit 
different than the actually text-based-message linux kernel list, where 
it's purely a problem of the raw number of single-segment text messages... 
when they're archived over N years as on gmane.)

This used to be a far worse problem back in the 32-bit era where max app 
memory was 4 gig at best (more likely 2 gig, and that's assuming you 
actually had multiple gigs of physical RAM!!).  Where now it's millions of 
headers triggering a problem, back then it was a couple hundred thousand... 
or even a few tens of thousands on less memory-endowed systems!

But of course that was before disk space was cheap enough that long 
retention (more than a few days or weeks) was common, too, so most servers 
didn't /have/ more than a a couple hundred thousand headers on even their 
busiest groups.

-- 
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