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.