Thunderbird 115

[Andy Bennett]

Yup, sure am!

[Tim Lamb]

OK

I left that on 20 seconds.

As a supplementary: I have messages saved under my defunct Demon address. If I delete this from my mail address list will these messages continue to be saved?

[The Natural Philosopher]

Well, yes. In the case of thunderbird it was a dogs breakfast that had been hacked so many times that it was un-maintainable, and I sort of applaud the decisions to 'start again' with the user interface. But as will all these major overhauls it will take a year before it settles down

[Andy Burns]

so unless you spend more than 20 seconds displaying/reading each message, it won't reduce the counter

do you mean the address book, or the list of email accounts?

easiest fix is to create a Demon folder under local folders, and drag all the old messages into there, before deleting anything ...

[Tim Lamb]

Oh! I didn't appreciate the way it functions and wanted to avoid finger fumbles. I'll try 10 secs.

Delete from the list of accounts.

Ok. I might manage that:-)

Thanks.

[SteveW]

I'd be quite happy with 115, except that it runs painfully slowly for me. switching from reading email to news takes 30 to 45 seconds. Switching news to show unread items only can take a minute. Something is decidedly wrong.

[Paul]

Best guess, your Profile Folder is gigabytes in size.

If you watch with ProcMon on windows (sysinternals.com) , you can watch what files it "touches" at startup. Someone noticed it sniffing everything in there. If you have left moribund materials in a profile folder, which could better live elsewhere, maybe moving them out of the way would help.

Or at least, your ProcMon adventure (filter on CreateFile and ReadFile), will give you time stamps and filenames, so you can tell what was sniffed, and how long it is taking for that sniff.

Linux has strace and truss and the like, which shows the access of file handles, but not in the same way as the Windows utility (which uses ETW subsystem).

*******

Some changes to the viewing format of newsgroups, requires re-writing the Mork file for the group. The Mork files may not necessarily be all that big, so that's not really a good excuse. Changing from threaded to unthreaded or vice versa, might cause file re-writing. A file is re-written, with the expectation it speeds up the presentation of the new format, the next time the program is opened. Mork files are parsed character by character, so there might be efficiency issues with the handling of it.

I have a test install of 115.3 for Linux on the other machine. The files are text for the most part, even if they don't make sense. The large file here, is optional, and I used Offline/Sync mode with USENET, to collect that file containing a thousand messages of Thai Spam. I did that to test the filtering capabilities. Of the thousand messages, only four of the messages were not spam. This is an ongoing flood in C.L.C. thanks to Google Groups.

bullwinkle@CRUISE:~/.thunderbird/4c8w8ja4.default-release/News/freenews.netfront.net$ ls -al total 18440

-rw------- 1 bullwinkle bullwinkle 17160873 Oct 5 04:30 comp.lang.c

-rw-r--r-- 1 bullwinkle bullwinkle 130 Oct 5 04:24 comp.lang.c.dat

-rw-rw-r-- 1 bullwinkle bullwinkle 436961 Oct 5 04:30 comp.lang.c.htm

-rw-rw-r-- 1 bullwinkle bullwinkle 158906 Oct 5 04:39 comp.lang.c.msf

-rw-rw-r-- 1 bullwinkle bullwinkle 1101792 Oct 5 04:06 hostinfo.dat

-rw-r--r-- 1 bullwinkle bullwinkle 25 Oct 5 04:05 msgFilterRules.dat

bullwinkle@CRUISE:~/.thunderbird/4c8w8ja4.default-release/News/freenews.netfront.net$ file * comp.lang.c: Unicode text, UTF-8 text comp.lang.c.dat: ASCII text comp.lang.c.htm: HTML document, Unicode text, UTF-8 text, with very long lines (373) comp.lang.c.msf: Mozilla Mork database, version 1.4 hostinfo.dat: ASCII text msgFilterRules.dat: ASCII text

Two of the files are server-wide, four of the files are newsgroup-specific. With the .htm being out of place and perhaps an exhortation to donate money or something, to the Thunderbird project ? In any case, you can try examining these files with a text editor, and make your own notes.

Paul

[Paul]

Turning off HTML rendering, in USENET, and using it as a USENET reader only, should prune some of that.

Paul

[Andy Burns]

As a datapoint, my profile folder in 3.7GB, I have zero issues with speed in TB (115.x or prior) ... yes TB can be quite memory hungry, eats the best part of 1GB

[Paul]

It actually eats, as much as it needs :-)

Try feeding it some pathological mail boxes and watch the fun :-)

It's no problem for it to use 16GB of RAM. But nobody is likely to have files that big in the first place. I had to make those test mail boxes programmatically (in C).

Paul

[SteveW]

It shouldn't be that. I only put 115 on as it was a fresh install after a clean install of Windows 11, following uogradinf with a new motherboard, processor and memory and wiping the SSD.

After installing it repopulated the emails from my home IMAP server and download headers from here.

I have tried deleting and rebuilding the profiles, with no improvement.

Previously, on the old system, I was running a slightly older version of TB with no problems - connecting to the same servers.

[SteveW]

The profiles folder, with 5 user profiles is less than 14MB!

[Andy Burns]

I have heard other people, in other places say that fresh profiles run slow, but upgraded profiles are ok, can't explain why, or even know if it's correct ...

[Jeff Layman]

FWIW mine is 3.3GB, and for some reason today TB (102.15.1) has been running really slowly. For browsing, PM has also been running a lot slower than usual, but FF isn't too bad. A speedtest for download didn't reveal any obvious problem.

[Paul]

Is it continually pulling info from your IMAP server ?

I tried some tests here, and it did seem to be a bit slow to "Mark all read" for USENET posts, which seemed to involve re-writing the Mork file.

On a Linux TB115, "top" said it was using 3.5GB of RAM. On Windows, TB115 was in the low hundreds of megabytes of RAM. This means there are some differences on whether RAM use is explicit or implicit.

On my 3.4GHz ageing Intel, it seems to manage to read the Mork at 33MB/sec to 40MB/sec or so. It may be relying on the System Read Cache in Windows for some of its performance, instead of MMaping files or keeping them in "charged RAM" that Task Manager can track. The old Thunderbird used to juggle Mork files in RAM, keeping them open if they were being used, and closing them during periods of idleness.

My initial impression, is Mork is a real bottleneck, and some of the features of the new program are silly (summarizing a thread by washing back and forth through the HTML engine).

It does not seem to respond to the HTML rendering setting. I want the damn HTML switched off ENTIRELY as an attack surface. I don't want the tool puttering around with incoming data and doing stuff. It's fine that the entire three-pane view is made from HTML, as that is sanitized internal data. But doing wretched things with the posted messages, isn't a good idea. Take making a summary of the BASE64 Thai spam for example. Is that safe ? I just don't like the possibilities there.

Summary: Yes, it's slow. And the Mork used to be a bottleneck, and it now seems to be even more of a bottleneck. They have an architect now ? My ass :-/ The reason I am harsh in judgment, is the new architect threw shade on the work of his predecessors, yet what he brings us, is not a Sparkle Pony, but more of a swayback nag. "The Mork handler should be written in Assembler" :-) Software people love it, when the user audience sez that :-) Well, they de-optimized it, and now they can f****ng well fix it again. The previous Thunderbird effort, they struggled to get as far as they did, in the Mork handling.

Mork is handled character by character, as far as I know. And like a Run Length Encoded compressor, handling a character at a time, brings processors to their knees.

Paul

[The Natural Philosopher]

How did you get top to show that? mine says 5.7%

[Andy Burns]

'm' toggles through several memory display styles

[The Natural Philosopher]

29Mbytes here.

[Sam Plusnet]

It's odd that "Verschlimmbesserung" was pretty much unknown in English - until software started to play a big role in our lives.

[Paul]

At this point, we need Steve to have a look at what he is doing, and spot the slow bit of it. I'm not reproducing his setup really, and I just wanted to do a general check of the thing.

Here's a picture of a "top" from a run on Linux Mint 21.2 TB115.3. I used SimpleScreenRecorder, to shoot video, because my keyboard doesn't have a PrintScreen. The machine has a second keyboard (PS/2) with a PrintScreen, but I have to walk over to use it, and by then, a fleeting moment could be past. So I just shot some vid to get this, then picked out a frame that was composed enough so you could read it.

[Picture]

The virtual is high, but not a lot is resident. About 570MB resident. The tool is in the process of marking a newsgroup "All read" and the CPU is railed on a core for a number of seconds before it is done with it. It's the same on the Windows version. Walking a Mork takes time. And yet, it's the Mork, because I can see that in ProcMon.

By applying memory pressure to Linux, we can shrink down that virtual, but what's the point ? We know that isn't all that interesting a phenomenon, so move on.

Paul