Adam said:
Just posting this message takes 138 MB RAM. It's kind of a resource hog.
Just posting this message, takes 321MB of RAM.
But, there's a good reason for that. My biggest .msf
file is 48MB. All the .msf files are open right now, and
held in memory. That's the memory consumption. The fewer
or smaller the .msf, the smaller the memory footprint.
I can clean up the .msf files. If I delete .msf and .dat
for each newsgroup, they'll be re-created. And they will be
smaller (as only the current articles on the server, will
define the file content). My 48MB .msf, contains the headers
of the last five years of the newsgroup in question. Those
could be safely tossed.
I would be able to significantly reduce the 321MB figure that way.
*******
Another option, is recent versions of Thunderbird have a timer set
to five minutes, which closes unused .msf/.dat pairs. So if you
have newsgroups in your list, which you have not accessed in the
last five minutes, that amount of RAM won't be needed. These are
supposed to be the entries in Configuration Editor, that control the
behavior. The 300000 number is milliseconds, or five minutes.
mail.db.idle_limit 300000
mail.db.max_open
*******
Of course, a news client doesn't have to be designed this way.
Years ago, on a Unix box, I used a news client that kept only
an .rc file (keeps high_water, low_water, and tracks articles
which have been read, a string of numbers). The .rc file is tiny,
perhaps half a megabyte at the time. No record at all is kept
for each newsgroup. So the .msf/.dat pairs are totally unneeded.
Of course, the .msf/.dat pairs on Thunderbird, are capable of
keeping more history than the event horizon of the news server,
and you can debate whether that's an essential feature or not.
If I click on an old article in there, it doesn't load, because
it's no longer on the server. All I can see is headers of messages,
not the bodies.
You can debate whether the feature set of Thunderbird is wise,
but the memory consumption can be traced to how you're using
it. There are people who never clean mail folders, who use
2GB of RAM, but that's their fault.
The reason the files are kept in memory, is a performance
trade-off. On a slow computer, the initial parsing time for
a large .msf might be significant. The design decision is
to keep it in RAM. My experience here on my processor, is
that isn't an issue. If the files were not kept in memory,
it would only slow things down a little bit. If I was
running on a 300MHz Celeron, I would think otherwise.
I would load the newsgroups once in the morning, and
go make coffee while it happened.
If I set mail.db.max_open to "1", I expect that would
significantly reduce the memory footprint. I have plenty
of RAM, so it's a non-issue.
*******
I only consider a tool "broken", when no tuning knob is available.
I prefer that programs make good choices on their own, but when
a complicated program offers tuning adjustments, it's a second
best option. Now, if the Configuration Editor had popup
balloons to explain what the settings did, *that* would be
a good design. You have to comb the mozilla.org site, looking
for hints.
Paul