Open Bug 1865657 Opened 10 months ago Updated 2 months ago

slow to delete email when next message has html newsletter with high activity in sViewManager, Paint and webrender

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Version:
Thunderbird 115
Type:
defect

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: lohner, Unassigned)

References

Details

(Keywords: dupeme, perf, Whiteboard: [has performance profile])

Attachments

(2 files)

imap log - 1_log_file.moz_log
329.77 KB, text/plain
Details
imap log - 7_log_file.moz_log
391.07 KB, text/plain
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0

Steps to reproduce:

I have a lot of mailboxes, and up to 115.4.2 (or .1?) on Win11 (not tested yet on Linux) TB was very slow when switching mailboxes or switching from mail to mail. I have a lot of mailboxes (>200) with lots of mails being autofiled (getmail & imapfilter). Since 115.4.3 TB has become MUCH more responsive (folder switching and going through text only mails), but is still slow when deleting a mail and the next one is not plain text but one with HTML content.

Actual results:

Summarizing:

  • works fine (normal speed):
    ...switching folders
    ...switching to text only mails

  • slow
    ...switching to HTML mails (or maybe only UNREAD HTML mails since that required HTML processing and IMAP action?)

I will pay more attention to the exact situations where it is slow vs. fast over the next day or two and update this bug. Is there any profiling I can run to show what takes the time (IMAP interactions, HTML rendering, folder switching, etc.)?

Update... just tested:

  • marking a folder with all HTML mails "read" and then deleted one at a time, that's still SLOW
  • marking a folder with all HTML mails "read" and then just SWITCHING from mail to mail... FAST
  • deleting already read and accessed mails: SLOW

It appears to be that the IMAP deleting is slow (or maybe it is synchronous and waits to complete before switching to the next mail?). Funny that with text mails (which are usually smaller) it is quick, and for HTML (or maybe all larger mails?) it is slow.

More tests:

  • deleting mails in the 100-200kb size range is slow (2-3 seconds from deleting one to TB showing the next mail)
  • deleting 10 of those mails takes about 12 seconds (timed)
    So it could be that either the IMAP or local deleting is slow for larger mails.
Summary: HTML mails very slow to load → Large (IMAP?) mails slow to delete
See Also: → 1861872
Keywords: perf

Reporter Nils,
I'm not seeing a problem deleting a single or group of 10 html emails in the 190k size range.
They delete and appear in trash folder almost instantly for me.
Is TB otherwise using a lot of CPU? Or maybe another programs is?
Note to me: put 100 190k "freesurfer" messages in cyrus 111 folder for delete testing.

CPU load is definitely not an issue.
Just updated to 115.5.0... still there.

I think the slowness happens when there are parallel "Bringing folder ... up to date" and Indexing operations ongoing. Then even the menus are a little sluggish. I'll keep an eye on this in the next week or two and update here if I see anything else. Right now I'm deleting 100-200KB mails from a list one at a time and the speed seems normal.

What else is strange is that I'm deleting the mails one at a time, but in the activity manager it usually says "Moved 1 message from <folder> to Trash" but in between also often says N messages (N=~3..15) so there appears to be a queue of deletions happening, this does not cause a slowdown though. Mailserver is a locally hosted dovecot, so network speed is not an issue.

Indexing for global search can be a bit of a cpu hog from what I've observed, especially if you've added a ton of new messages (like if you copy them in from another server).
When I delete one at a time, I just see one entry in activity mgr that increments the delete count. So not sure what you mean by "says N messages (N=~3..15)"
Specifically, after deleting one at a time 5 message I see only this in Act. Mgr:

Moved 5 messages from 111 to Trash               14:40
gene@localhost.cyrus

Nils, I've never seen the Act. Mgr as very reliable or useful for resolving issues. So to know better what is going on, an IMAP:4 log might be more helpful to see what's happening when you delete messages. I think on another bug you probably attached an IMAP:4 log as described here: https://wiki.mozilla.org/MailNews:Logging

Is there a debugging for local operations as well? I'm not sure if this is just an IMAP topic or a mix of IMAP, indexing and updating folders...

(In reply to Nils from comment #7)

Is there a debugging for local operations as well? I'm not sure if this is just an IMAP topic or a mix of IMAP, indexing and updating folders...

There may be but I'm not real familiar with the other logging types and, when I've used them, they don't tell you that much. So I think just looking at IMAP and possibly first eliminating it as a cause may be the most productive.

Sorry, don't have much time for dedicated logging at the moment, but I saw that its sometimes downloading into and indexing the same folder at once... and then once the indexing stops it goes back to normal speed. It would probably make sense to allow only one operation on the folder at a time.

Just observed the same again... deleting small mails leads to immediate indexing operations, and as soon as indexing starts, even deleting small mails slows down. This is again only seen in the activity manager... will try to log IMAP when I get the chance. But I'm leaning towards this being a local resource usage conflict (deleting / trash & IMAP update, indexing in parallel, already opening the next mail and displaying, ...) withing TB, rather than an IMAP issue.
Maybe the indexing should wait until the user has been inactive for a few seconds (and pause when the user becomes active)...

Question... I just deleted about 200 unread 2kb mails with the Delete button one after the other... a few of them (40-50) showed in the Trash as unread. Probably from a group where I hit Delete fairly quickly without waiting for the display to advance.
I guess this means that when I delete one it jumps to the next, and before it can mark it as read it deletes that one (in "unread" status)... is there a queue of IMAP actions that may be getting skipped and overwritten? Would the IMAP logging catch that?

Hi Nils,
First off, in comment 0 you wrote:

Since 115.4.3 TB has become MUCH more responsive

Is this compared to 102 and earlier? But I think you mean with respect to earlier 115 versions? (FWIW, I haven't really seen anything that is faster with 115 and later dailies/betas compared to 102, but I don't use all the features.)

From comment 10:

Maybe the indexing should wait until the user has been inactive for a few seconds (and pause when the user becomes active)...

I don't know much about how indexing works. But it doesn't seem like it should kick in just when you delete a single message. If it does, that's definitely not an imap or network issue. Also, as you probably know, if you don't need the global indexing, you can turn it off in the settings.

From comment 11:

Question... I just deleted about 200 unread 2kb mails with the Delete button one after the other... a few of them (40-50) showed in the Trash as unread. Probably from a group where I hit Delete fairly quickly without waiting for the display to advance.
I guess this means that when I delete one it jumps to the next, and before it can mark it as read it deletes that one (in "unread" status)... is there a queue of IMAP actions that may be getting skipped and overwritten? Would the IMAP logging catch that?

This may depend on how you have the "mark as read" feature set. I personally keep it turned off since I prefer to mark message unread manually. But if, if you have it set to immediately or after X sec, it may or may not get marked by imap as read before it gets moved to Trash. It definitely won't if X is several seconds and you are deleting mail quickly. Even immediately might not mark the message read fast enough if you are deleting quickly.
If you have a long list of unread messages to delete and you don't want them to appear unread in trash, it might be better to select the whole group, mark it as read, and then delete the group. That would cause it to occur in probably one or two imap commands.
I don't know of any IMAP "queue" of messages that would occur while deleting messages.

I do have the mark as read feature set... when I flip to a mail it's marked read.
I just tried with the indexer off, and it doesn't seem to change anything.
Turning off Mark as Read as well might speed up deleting small (2kb) mails a little, but with ~70kb mails it doesn't seem to change anything either. I guess i need to do the IMAP logging when I have time.

Hello,

Just want to jump in here and mention that i was also having the exact same issue of super slow deleting.

I just installed the most recent beta release, 122.0b1 and slow deleting seems to have been resolved.

Nils, perhaps try the newest build and see if it is also fixed for you?

Hate to contradict myself, but i just deleted a group of ~10 emails on the most recent version and tb locked up for 20 seconds or so, so i would say it has not been resolved. 🤦‍♂️

dan and Nils,
Maybe this somehow depends on your imap server type. Can you tell me the imap server you are using or which server you are seeing the slow deletions on? (I've corresponded with Nils before but don't right off remember his server type.)

Another thing to try is make a new folder or find an existing folder that is empty that you don't mine using for a deletion test. Then go to another folder with some fairly large messages and select a group of messages (maybe 100 messages) in that folder. Then COPY (don't MOVE!) the group to the test folder. Is that operation fast or slow?
Then after you have copied the messages to the test folder. Select ALL the messages in the test folder and delete them. Is that operation fast or slow.
Then empty the trash folder. Is that fast or slow?

You can repeat this sequence a couple of times to see is the operation times vary.

Hi Gene,

I experiencing this with two different mail servers - one hosted by ionos - i'm not sure what they're using as it's just a service i use for my personal domain, i don't actively manage it.
The other is a work server that i do personally manage. The server is almalinux 8.9 running a pretty standard dovecot installation.

I will give these scenarios a test. Accumulate some emails into a folder, try moving them between folders and then deleting them in bulk.
I'll let you know the results.

As a sidenote, this was not an issue with either server on another mail client (windows mail, which is junk in every other respect) - but perhaps they had some workaround like reflect the change locally before the server responded to improve ux? who knows. but i'll let you know.

Dan,
If you see this on dovecot server then probably not server dependent since it's always very stable.
I think Nils is doing the deletes on windows, but I don't think you have said if you are see this slowness on linux or on windows or possibly mac (or maybe both/all?).
So far, I've only tested this on linux and don't see it.

Tried it on win11 with tb 115.6.0 and deletions or copies seem to work as they usually do. No delay or lag.

I am also on a locally hosted (FreeBSD) Dovecot. I am running on windows, but can also try Ubuntu...

So to know better what is going on, an IMAP:4 log might be more helpful to see what's happening when you delete messages. I think on another bug you probably attached an IMAP:4 log as described here: https://wiki.mozilla.org/MailNews:Logging

Another approach is to create a performance profile https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance, although it may not be sufficient information for Gene.

Component: Untriaged → Networking: IMAP
Flags: needinfo?(lohner)
Flags: needinfo?(dan)
Product: Thunderbird → MailNews Core
Whiteboard: [needs protocol log]

Okay.
Firstly, I am running TB 122.0b1 on windows 11, not 115.x.
I used a sample size of 92 messages - Currently, my Entire inbox. These messages aren't necessarily large, just average/basic email, some plain text, some html, but nothing extravagant.

On my first attempt, the copying was pretty quick for all 92 messages, maybe about 10 seconds total, but it did block UI thread briefly while it loaded.
I then deleted the copies from the test folder and it was very slow, UI thread blocked entire time.

I then did the exact same thing with the same messages a second time.
This time to copying operation was much slower (maybe a minute), locking up the UI thread the whole time.
Deleting this time was just as slow, maybe slower, ~ 5 minutes. ui thread blocked. I profiled this one.
Here is the link: https://share.firefox.dev/47kTIAN

Flags: needinfo?(dan)

Wayne, Do you see anything suspicious in the profile https://share.firefox.dev/47kTIAN

Dan, Thanks for the profile, but I'm not an expert on these, as Wayne alluded to, but it doesn't look like a lot of CPU is getting used during the 5 minutes or so. I see a blip at the start that doesn't appear to by TB copy/move related, then two smaller blips in the middle that do show some copy activity but nothing extreme. Then at the end there's another non-copy/move related blip.

Maybe Wayne can tell more by looking at the profile, but I don't see anything that looks bad.

I tried the test again with a folder with 53 messages and moved the messages back and forth several times between two imap folders on the same server. I don't see any UI hang while the copy/move is in progress (I can scroll through stuff fine immediately after initiating the transfers).

I'm on a self-built, unoptimized daily build 123.0 so it's not always the fastest, but I see no problems or UI hang ups when doing transfers.

I typically run without offline store so I set the test folders I was doing the transfers with to use offline store and I didn't see a difference.
If your test folders have offline store, TB tells the server to do the copy/move. But then at the destination folder, tb has to first upload all the new message headers and then it upload message bodies that you select and in the background it uploads the remaining bodies (a process called autosync). Autosync is pretty easy on the cpu (as I've always seen) and happens quietly without blocking anything.

So unless Wayne sees something in the profile that I don't see, I think the next step is record the IMAP:4 log while doing your transfers and attach it above or you can email it to me. Re: https://wiki.mozilla.org/MailNews:Logging

Flags: needinfo?(vseerror)

Dan, Are your folders using offline store? If so, are you using mbox (the default) or maildir? I've only tested this with mbox.
Another possibility is that your offline storage has gotten extremely fragmented due to message deletion and addition over time. You might try "compacting" the folders to get rid of any previously deleted messages still hanging around in the mbox file(s). (You may have seen prompts pop up about this asking you to compact your folders when there is too much wasted space in the storage files. And maybe you ignored the prompts or they just never occurred.)

Hi Gene,
I noticed the same thing on profile - i only know so much about them too, but cpu usage was minimal. To me, it looked like a small spike as i initiated the delete action, then the main UI thread is blocked for ~5 mins, and then another small spike on UI redraw and thread becomes active again.
The profile does not contain the copy actions, just the latter delete action.
I'm not sure if I am using offline store? I opened properties for the inbox and tried the "Repair Folder" button, which did fix some messages that got mixed into threads they shouldn't have been in, but deleting a single message still resulted in TB hanging for ~10 seconds.

I'm going to attach the imap log i've made of deleting a single message and 7 messages. prefixed 1_ and 7_
First one, is deleted directly from inbox.
Next one, 7 emails are copied to "test_rm" folder and then deleted from there.
By deleting i mean they're technically moved to the trash folder.
I closed thunderbird shortly after the main UI thread unlocked so that there wasn't too much additional noise in the log, but it looked like the log just kind of cut's off at the end, as if it didn't finish flushing the log buffer or something..? If i need to do something differently, let me know.

Few things of note:

  • My trash folder had 3600+ emails. I cleaned it down to ~200, but this did not change anything. However, interestingly, the permanent deletion of ~3400 emails executed nearly instantly (<1s) and no thread lock up occurred.
  • This computer uses folder redirection, so the APPDATA folder where the local copies of the emails are stored, is actually on a server (local, about 20 feet from me, but still.) I could see this potentially being a bottleneck, however I only very occasionally experience delays in opening other files, and this issue in thunderbird occurs every time i try deleting (moving to trash) emails...so i'm inclined to believe this is not the issue.

Also note about the logs - they're all happening on the dan@fbach.us email, ionos.com server.

Dan, The logs look fine doing the copies and moves.
The cut-off at the end of the 7_ log looks a bit strange but don't think it is related to the issue at hand. Almost looks like TB crashed or was shutdown by killing it rather then using using the X or close menu item(s).
Was the log being recorded on the remote file server (smb/samba?) or on the local filesystem? Not sure if that might cause the sudden cut-off.

Anyhow, maybe you can provide a bit of historical info. Did this problems just start with a recent TB release? I supposed you had this problem with an earlier release since your first comment here suggested that beta 122 actually fixed the "slow to delete" bug. So do you remember the latest tb release that didn't have this problem?

When you didn't have the problem, were you using the exact same remote file server setup?

I'm not sure if I am using offline store?

Well, since offline store using mbox format is the default, you probably are. Probably the easiest way to check is look at a folder property (right click the folder and select properties). Then look at the "Synchronization" item. If the box "Select this item for offline use" is checked, the folder is using offline store.

Another way is to open the account settings and look under "Synchronization and Storage". If the first check box "Keep messages in all folders ..." is checked then probably all folders for the account have offline store. You can look under the "Advanced" button there and open the ionos account and check to see exactly which folders have offline store. I'm not sure if Trash folder has offline store by default since most users don't care about keeping a local copy of messages they put it trash. If it does, you might try disabling offline store for trash (you can do it with the folder properties too) then empty trash and restart TB and try to delete to trash again. That will avoid TB from having to populate the the trash mbox file with the bodies of the deleted messages. You might try this (disable offline store) for other folders too (the source and destination folder) to see if it improves the copy speed to the folder. That might tell us if the transfer to the remote filesystem is somehow slowing down TB since then only the headers will be stored in remote folder files without full offline store.

Okay, well after many different configurations I think I have at least something we can work with.
I tried disabling Offline storage for the individual folder i was copy to, deleting from, and that did not help.
I then thought i would try disabling it account wide. This seems to have helped the problem, but not eliminated it entirely. Some copy/delete operations have sped up, some have not.

I honestly have a hard time believing that my local fileserver is the bottleneck though.
User accounts are stored on an enterprise grade nvme ssd's, that easily run faster than the network, network switches are all gigabit switches or better... If i copy a 1GB file from my local drive to it, it runs at 100MBps, and i do mean megabytes, not bits. so I truly don't believe there is a bandwidth issue.

Only other thing i can think to do is copy down tb source code, run it in visual studio, trace and see what happens for myself.

I'm not implying that your network isn't fast enough. I'm really more thinking that it's TBs reaction to the network that is causing the slowdown.
That's why I asked at what version of TB you started seeing the problem.
Also, I didn't ask directly, but is your network using windows SMB protocol or something else. I'm in the process of setting up an SMB connection to a linux smb (samba) server to try to see what I see when using a remote network. Been a while since I've done this kind of thing and am having "permission" problems getting it work.

Finally got the file server to work and copied my dovecot TB account mbox and database files there and pointed the TB server setting to them. My network is just standard wifi and not high-speed ethernet so probably not the fastest. What I see seems very consistent and doesn't vary a lot. If I move about 300+ messages between folders, there's about a 15 second UI lockup. I'm checking by trying to scroll the folder pane right after starting the move and it doesn't react until about 15 seconds. I compared this same activity using the local filesystem and there is still about a 5 second UI freeze, which is also consistent. This is with 122 daily un-optimized on linux.

I then tried it with a pre-supenova un-optimized build I still have around (110 daily, also linux) and with remote storage filesystem it is actually slower. It hangs the UI for maybe 20 to 25 seconds when doing the same move.

I don't see any difference between using 2.4GHz wifi or 5GHz wifi. Not sure if that means anything. (I don't know my exact bits/bytes per second.)

But I'm never seeing anything like the 5 minute UI hang that Dan has reported, even after doing the 300+ messages moves between folders a lot of times.

From comment 25:

My trash folder had 3600+ emails. I cleaned it down to ~200, but this did not change anything. However, interestingly, the permanent deletion of ~3400 emails executed nearly instantly (<1s) and no thread lock up occurred.

I don't see any UI hang when emptying trash folder either. That doesn't require copying/moving any files over the network. Just deletes files and tells the server to expunge all the messages it has in Trash.

This computer uses folder redirection, so the APPDATA folder where the local copies of the emails are stored, is actually on a server ...

But where your TB is installed (in Program Files, I assume) is on the local filesystem, right?
For my test I just copied the the profile files that were under <Profile>/ImapMail/ to the mount point of my remote filesystem (mnt) here, as seen on TB's "Server Setting" config screen:
Local Directory: /home/gene/mnt/wally.dbnet.lan
So I didn't put the complete profile on remote filesystem, just the part containing the mbox files and the database files containing the header info (i.e., the primary files that are read and written during runtime).

I also tried this same setup on win 11 and see about the same UI freeze time. This was with release 115.6.0 and the latest daily on win 11 (both optimized).

To maybe repeat myself, the 15 second UI freeze when I start the copy is very consistent. From what you (Dan) are saying, it sounds like the freeze time is somewhat random. The freeze time is proportional to the number and total size of the messages copied to the other folder. It also depends on whether the destination folder has offline store. With offline store, a copy of all the messages into the destination folder occurs which can significantly lengthen the UI freeze.

Another issue I've observed is that autosync is unnecessarily causing two copies of each message to appear in the mbox destination file after a copy. The first copy occurs because the source messages are all first copied to the destination mbox (a filesystem copy so doesn't involve the imap server). Then autosync incorrectly causes each message at the destination to be fetched from the server and also added to the mbox. This causes the mbox file to become twice as large as it should be but this doesn't freeze the UI. The UI freeze only occurs on the initial copy of the destination mbox from the source, probably because this copy occurs on the main/UI thread while autosync occurs on the imap thread(s). Doing a compact on the destination folder causes its mbox file to become half the size, which would be expected.
Not sure if this is something I introduced when I made some changes to autosync a while back (bug 1776823), and also don't think this is a cause of the reported bug, but I need to look again at autosync.

Dan, you might try setting mail.server.default.autosync_offline_stores to false to see if it makes a difference. My guess is that it won't but who knows... (You should do a tb restart when changing a hidden pref like this.)

Okay, so minor update. When I disable the offline storage entirely, it seems that the issue is resolved.
As it happens, restarting tb after making the account offline is key to applying this change.

Curiously, when i move email around, even with offline storage disabled, the files in my profile .../AppData\Roaming\Thunderbird\Profiles\4r6m7rjn.default-beta\ImapMail\imap.ionos.com\ are still updated as things are moved around and changes occur instantly, but there is no UI hang at all.

On a side note (and perhaps such a change is outside of your/this bugs scope) but for the best UX would it not be most prudent to run these threadblocking operations off of the main thread, so that even the 15 second UI block you're experiencing does not occur?

I am going to re-enable offline storage and want to watch the offline email files change. Where in the profile are they stored? somewhere other than the ImapMail folder? I want to watch and see if the files are changed instantly (as they are now with it disabled) and perhaps some other action related to the enabling of offline storage is causing the lockup, not the file operations.

And yes, TB is installed locally.

From comment 32:

Another issue I've observed is that autosync is unnecessarily causing two copies of each message to appear in the mbox destination file after a copy...

I determined that the mbox file of my source folder for the copy was actually imported from another mail program. It was a mbox file of about 17k message from a mailing list that someone sent me and was somewhat corrupted in that TB was seeing problems with some of content (maybe unescaped "From "s, see below) so it asked the server for some of the messages again (not actually all of them as I stated above). So these corrected messages were just appended to the file. When I do a "compact" on the folder all the corrupted messages are removed. So, if I do the import with a "good" mbox created by thunderbird, I don't see the issue. Anyhow, not really the subject of this bug.

From comment 34:

Okay, so minor update. When I disable the offline storage entirely, it seems that the issue is resolved.
As it happens, restarting tb after making the account offline is key to applying this change.

When I change a folder between off and online, I usually do it via the folder properties and then close folder properties. Then I open the folder property again and do a repair of that folder. I'm not 100% sure this ritual is completely necessary but it works for me. Maybe restart would have a similar effect, but I doubt it. To get rid of the mbox file (see below) you have it either repair the folder or manually delete the mbox file.

Curiously, when i move email around, even with offline storage disabled, the files in my profile .../AppData\Roaming\Thunderbird\Profiles\4r6m7rjn.default-beta\ImapMail\imap.ionos.com\ are still updated as things are moved around and changes occur instantly, but there is no UI hang at all.

For each folder there is a <folder-name>.msf file. This file acts as a database for the folder and contains the header items needed by TB (not the complete message header, and the file is not very readable). If you don't have offline store for the folder, <folder-name>.msf is the only file for the folder.
For each folder with offline store there is also a folder called just <folder-name>. It contains a complete copy of each email including all the header lines. Each email is separated with a "From " line. So this file (in readable mbox format) can get huge depending on how many messages are in the folder.
If you have sub-folders, the .msf and mbox files will be in directories under your \imap.ionos.com\ named <folder-name>.sdb

I am going to re-enable offline storage and want to watch the offline email files change. Where in the profile are they stored? somewhere other than the ImapMail folder?

All your top level folders will be under your .../AppData\Roaming\Thunderbird\Profiles\4r6m7rjn.default-beta\ImapMail\imap.ionos.com\ with names <folder-name>.msf and (if folder has offline store) just <folder-name>. Or they will be under <folder-name>.sdb or deeper if your folder of interest is a sub-folder.

On a side note (and perhaps such a change is outside of your/this bugs scope) but for the best UX would it not be most prudent to run these threadblocking operations off of the main thread, so that even the 15 second UI block you're experiencing does not occur?

Good point. However, I never noticed this just doing a copy/move of a few messages. I only just noticed it when doing a huge copy (e.g., 800 messages) for this bug. When I try to copy even more (like 17K messages) the delay is even longer.
But what you report (and I think Nils too) is you see a UI lockup when only copying a few messages or when deleting them (which is also a essentially a copy operation if you are configured to deleted to Trash, the default). And the delay occurrence is somewhat random and not correlated to number of messages being copied.

Hey Gene,

Thanks for the detailed writeup. Understanding the various inner workings is helpful for troubleshooting.

That said, i just ran my little experiment and here's what i found.
With offline storage on
I "deleted" 4 emails. (Moved from inbox to trash) All emails were quite small. ~30 seconds hang.
The Trash.msf file was updated instantly.
The Trash file on the other hand, was slowly changed (i watched the files size grow as the UI thread was locked) It changed 4 times, as you would expect. Moments after the filesize incremented the 4th time, the source .msf file is updated and the UI unlocked. The interval between filesize changes seems consistent, and possibly relative to the size of the destination folder. Is the file that contains the copies reparsed each time another email is copied/moved? I ask because my Trash file is ~340MB and the interval between file changes is long, compared to my test folder, where there is still some lag, but not even close to that of the trash.
I could see if some parsing or repairing is happening before each mail is moved, and that destination folder is large, the difference in lag on a local drive vs a remote drive could be dramatic. parsing through 340MB over hardware vs 340MB over network, are two very different things.

Okay little more here.
When I went from Online only to Offline storage, it downloaded ~1600 messages for the trash folder.
Trash was 340MB as previously stated.
I just repaired my trash folder and it went from 340MB to 121MB.
Now there is no lag in deletion.
How could the trash folder get that corrupt upon fresh download?! Whoa.

I think i discovered a bug with permanent deletion, which could explain why the trash was messed up, and perhaps the bug in its entirety.
It looks like when a message is permanently deleted from trash, the trash.msf file is updated, but they are not actually purged from the trash folder/file itself, until the folder is repaired.
So in comment 25, where i permanently deleted 3400 emails, the Trash folder itself was never cleaned or purged of those emails - when i turned offline storage off, the file remained and all of those emails remained. Then, now, when i turned offline storage back on, it still didn't repair that folder, i dont know what it did.
I just tested this by deleting a 6 or 7 emails from the trash and the trash.msf filesize changed, but the trash file/folder itself remained unchanged until i repaired it. The trash folder went from 124,649Kb before and after deletion, to 123,971Kb after repair.

Dan, I was writing this before I saw your comment 38:

(In reply to dan from comment #37)

When I went from Online only to Offline storage, it downloaded ~1600 messages for the trash folder.
Trash was 340MB as previously stated.

Was the Trash mbox file completely gone (or maybe at 0 length) before you went back to it having offline store? If not, it's possible that the download just added into existing Trash mbox file the same messages again. Then when you repaired the folder, it got rid of of the duplicates/orphaned messages and made the file smaller. (FWIW, I think just compacting the Trash folder would have done the same thing.)

I don't know the exact steps but when a message is added to mbox storage (Trash or a regular folder) TB/os has to get the file over the network into memory, write the new message to the file and send the file back out over the network. So doing this over a network takes some round-trips and will be slower I would think, even with the fastest serial network.

So you will probably get the best performance by just keeping Trash folder as not having offline store and making sure your other folders (with offline store) remain compacted to minimize their size. When you move a message or delete a message from a folder, the mbox file size doesn't go down at all. So to make the folder smaller you have to "compact" or optionally "repair" it. (Compact doesn't re-download from server but repair does, so I would recommend just compact after you've moved or deleted messages and you notice a performance issue.

Another possibility is to consider moving from default mbox storage to maildir storage. Maildir offline storage keeps each message in it's own file rather than putting all of them into a possibly huge mbox file. This may work better with filesystem over a network. You could try it with a new profile to see how it works with your setup.

I just repaired my trash folder and it went from 340MB to 121MB.
Now there is no lag in deletion.
How could the trash folder get that corrupt upon fresh download?! Whoa.

My guess is that redundant messages somehow got added to it, but not sure.

**** all the above written before seeing comment 38

(In reply to dan from comment #38)

I think i discovered a bug with permanent deletion, which could explain why the trash was messed up, and perhaps the bug in its entirety.
It looks like when a message is permanently deleted from trash, the trash.msf file is updated, but they are not actually purged from the trash folder/file itself, until the folder is repaired.

Yes, that is true and has always been that way.

So in comment 25, where i permanently deleted 3400 emails, the Trash folder itself was never cleaned or purged of those emails - when i turned offline storage off, the file remained and all of those emails remained. Then, now, when i turned offline storage back on, it still didn't repair that folder, i dont know what it did.
I just tested this by deleting a 6 or 7 emails from the trash and the trash.msf filesize changed, but the trash file/folder itself remained unchanged until i repaired it. The trash folder went from 124,649Kb before and after deletion, to 123,971Kb after repair.

Yes, until you do a repair (or probably better, compact) the mbox file keeps all its deleted messages. E.g, you can delete or move out all messages from a folder with mbox storage and the mbox file remains unchanged. Just the pointers to the messages in .msf file go away. Then when you add messages again to the folder the mbox file gets even bigger until you compact it.

More from comment 38:

So in comment 25, where i permanently deleted 3400 emails, the Trash folder itself was never cleaned or purged of those emails - when i turned offline storage off, the file remained and all of those emails remained. Then, now, when i turned offline storage back on, it still didn't repair that folder, i dont know what it did.

When you turn off offline storage, it doesn't automatically get rid of the mbox file. You have to manually delete the mbox and .msf file or do a repair of the folder you just set to not have offline store (I recommend just do the repair in this case).
Turning off offline store by itself just affects new message that come in after the change.

So, taking all of that into consideration, is folder compaction run on any sort of regular basis? It seems like, if not, folder corruption, and trash folder size issues, are inevitable, given enough time. I see the "Compact all folders when it will save over ##MB" setting, and it is enabled on my installation and set at 20MB - but it never ran in my case (when compaction removed >200MB) and TB had been opened and closed numerous times.
It also seems like if someone deletes a message, they would want it deleted, not just "marked" for deletion in a pointer file, while the actual data remains. If the overhead of compaction is minimal, what would be the hurt of compacting folders more regularly?

Lastly, what is the pro / con between mbox and maildir? I assume that TB chooses to use mbox over maildir be default for a reason.

(In reply to dan from comment #41)

So, taking all of that into consideration, is folder compaction run on any sort of regular basis? It seems like, if not, folder corruption, and trash folder size issues, are inevitable, given enough time. I see the "Compact all folders when it will save over ##MB" setting, and it is enabled on my installation and set at 20MB - but it never ran in my case (when compaction removed >200MB) and TB had been opened and closed numerous times.

Seems like it's working for me. I moved about 54M of messages to a folder with mbox storage and set the threshold to 60M and didn't see the prompt to compact. Then I set it to 50M and do see the prompt and it says I will recover 54M of data. I've also been seeing the prompt at other times (sometimes seeming to claim more saving that there is).

It also seems like if someone deletes a message, they would want it deleted, not just "marked" for deletion in a pointer file, while the actual data remains. If the overhead of compaction is minimal, what would be the hurt of compacting folders more regularly?

You could try setting the threshold very low and to do the compact automatically w/o a prompt. Maybe then it would do the compacts in background and keep your files smaller.

Lastly, what is the pro / con between mbox and maildir? I assume that TB chooses to use mbox over maildir be default for a reason.

I have a few test accounts on maildir and haven't seen a problem but don't use it for any "real" working accounts. I think mostly advanced users that want better backup use it since it's not default. There are some dire warning here: https://support.mozilla.org/en-US/kb/maildir-thunderbird but it doesn't appear that any serious bugs have been filed for it since a lot of effort by developer Ben Campbell went into really cleaning it up and separating it's functionality from mbox code. So I think the warning might be overblown. However, as I mentioned, I would first test it using a new profile so you can go back to using mbox if you prefer. (To add a new profile start TB with -p option in shortcut command line. i.e, <path-to-exe>\thunderbird.exe -p
Here a bug search for maildir.

If you look at the maildir bugs you might see some debate as to whether "compact" is appropriated for maildir. I tried to summarize the reason there is still a compact option here: https://bugzilla.mozilla.org/show_bug.cgi?id=1827973#c13. If you stay with the "delete to trash" you should never need to compact when using maildir.

One other thing occurred to me while looking at the tb support site and that is anti-virus software. They have been know to sometimes cause problems in TB. The only option in TB to deal with them is under Settings | Privacy and Security | Antivirus. You might try unchecking that item if it's enabled. I don't remember exactly what this does but if it's checked, unchecking it might help, but a long shot. I think it just saves each incoming email in a tmp file before putting it into mbox file so a virus scanner doesn't invalidate the whole mbox, so probably not relevant to your issue. (It doesn't actually cause TB to communicate with or hook into the anti-virus s/w in any way.)

Hi, I was just doing some more testing with deleting a lot of logfiles that accumulated over the new years break and saw something interesting... large mails (~60kb+) that were plain text deleted quickly (or the subsequent one showed quickly), and HTML ones took a while. So this may be a HTML vs plaintext rendering topic rather than an IMAP one?

Flags: needinfo?(lohner)

Sorry, accidentally deleted the needinfo... re-adding to myself for the IMAP logs

Flags: needinfo?(lohner)

Nils, can you copy the slow deleting html emails from Trash to a some normal folders and delete them again and see if they are still slow to delete? If so, maybe then attach the emails?

(In reply to dan from comment #25)

...
Few things of note:

  • This computer uses folder redirection, so the APPDATA folder where the local copies of the emails are stored, is actually on a server (local, about 20 feet from me, but still.) I could see this potentially being a bottleneck, however I only very occasionally experience delays in opening other files, and this issue in thunderbird occurs every time i try deleting (moving to trash) emails...so i'm inclined to believe this is not the issue.

It would be a mistake to exclude the file share as a possible cause. We have open issues that would be relevant - bug 1242042 and bug 905576 for example. I would encourage you to test with a profile on your local disk.

https://share.firefox.dev/47kTIAN is quite extraordinary, i.e. extreme. It does potentially point to the two bugs above.

Stack:
NtCreateFile
CreateFileInternal
OpenFile(nsTString<char16_t> const&, int, int, bool, PRFileDesc**) [xpcom/io/nsLocalFileWin.cpp]
nsLocalFile::OpenNSPRFileDescMaybeShareDelete(int, int, bool, PRFileDesc**) [xpcom/io/nsLocalFileWin.cpp]
nsLocalFile::OpenNSPRFileDesc(int, int, PRFileDesc**) [xpcom/io/nsLocalFileWin.cpp]
MsgGetFileStream(nsIFile*, nsIOutputStream**) [mailnews/base/src/nsMsgUtils.cpp]
nsMsgBrkMBoxStore::InternalGetNewMsgOutputStream(nsIMsgFolder*, nsIMsgDBHdr**, nsIOutputStream**) [mailnews/local/src/nsMsgBrkMBoxStore.cpp]
nsMsgBrkMBoxStore::GetNewMsgOutputStream(nsIMsgFolder*, nsIMsgDBHdr**, nsIOutputStream**) [mailnews/local/src/nsMsgBrkMBoxStore.cpp]
nsMsgDBFolder::GetOfflineStoreOutputStream(nsIMsgDBHdr*, nsIOutputStream**) [mailnews/base/src/nsMsgDBFolder.cpp]
CopyStoreMessage(nsIMsgDBHdr*, nsIMsgDBHdr*, unsigned long long&) [mailnews/imap/src/nsImapMailFolder.cpp]
nsImapMailFolder::CopyMessagesOffline(nsIMsgFolder*, nsTArray<RefPtr<nsIMsgDBHdr> > const&, bool, nsIMsgWindow*, nsIMsgCopyServiceListener*) [mailnews/imap/src/nsImapMailFolder.cpp]
nsImapMailFolder::CopyMessages(nsIMsgFolder*, nsTArray<RefPtr<nsIMsgDBHdr> > const&, bool, nsIMsgWindow*, nsIMsgCopyServiceListener*, bool, bool) [mailnews/imap/src/nsImapMailFolder.cpp]
nsMsgCopyService::DoNextCopy() [mailnews/base/src/nsMsgCopyService.cpp]
nsMsgCopyService::DoCopy(nsCopyRequest*) [mailnews/base/src/nsMsgCopyService.cpp]
nsMsgCopyService::CopyMessages(nsIMsgFolder*, nsTArray<RefPtr<nsIMsgDBHdr> > const&, nsIMsgFolder*, bool, nsIMsgCopyServiceListener*, nsIMsgWindow*, bool) [mailnews/base/src/nsMsgCopyService.cpp]
nsImapMailFolder::DeleteMessages(nsTArray<RefPtr<nsIMsgDBHdr> > const&, nsIMsgWindow*, bool, bool, nsIMsgCopyServiceListener*, bool) [mailnews/imap/src/nsImapMailFolder.cpp]
nsMsgDBView::DeleteMessages(nsIMsgWindow*, nsTArray<unsigned int> const&, bool) [mailnews/base/src/nsMsgDBView.cpp]
nsMsgDBView::ApplyCommandToIndices(int, nsTArray<unsigned int> const&) [mailnews/base/src/nsMsgDBView.cpp]
nsMsgDBView::DoCommand(int) [mailnews/base/src/nsMsgDBView.cpp]
XPTC__InvokebyIndex [xul.dll]

Flags: needinfo?(vseerror)

Hey Wayne,
For me, it looks like folder corruption was to blame for my slowness. Another bug I'm working on (bug 1873282) is folder corruption when mails are copied/moved between folders, of which deleting is, as they are moved to trash when deleted, which causes corruption.
Once I repaired all folders in the account, all actions sped back up and now i'm just seeing the normal, but occasional, 10-15 sec hang as someone with a local profile. Which is still kind of bad for UX and these tasks should probably be detached from the main/UI thread if possible, but that can be addressed separately.
I don't entirely discount the possibility of remote profile causing the initial corruption as the reason has yet to be determined...and I would say that the remote profile likely made the UI hangs more dramatic than they would have been if I had a local profile, but from the evidence that i gathered, there did not seem to be any actual lag in the file access and changes, so in my case i would say that the remote profile was not the primary cause.
Since my last comment, 8 days ago, I have not had any hanging issues...beyond the occasional 10-15 second hang that Gene also experienced.

...beyond the occasional 10-15 second hang that Gene also experienced.

I only see the 15 sec delay when I copy 300 messages. If only a few messages the delay is not noticed. If more than 300 it is longer. So, for me, it's not an "occasional" or "random" delay put proportional the the number of messages copied within the account and worse when using a network filesystem for the profile and better when not using offline store.

See Also: → 1873282

I think what I'm seeing is a non-IMAP issue. I was cleaning up lots of mails over the weekend and saw the following:

  • all mails were older and laready read
  • all mails were HTML in the 15-250Kb (typical newsletter size) range
  • Deleting each mail was slow
  • Deleting mails which I had forwarded where the thread was collapsed was FAST (i.e. almost immediate).

This leads me to believe that it's the HTML loading / processing / rendering which is slow, not TB itself or the IMAP interaction. This is on a Lenovo Carbon X1 Gen9 (2 years old) Laptop with plenty of memory and no load.

Not sure if we should rename / repurpose this bug or close it and file a new one specifically for slow rendering.

(In reply to Nils from comment #49)

I think what I'm seeing is a non-IMAP issue. I was cleaning up lots of mails over the weekend and saw the following:

  • all mails were older and laready read
  • all mails were HTML in the 15-250Kb (typical newsletter size) range
  • Deleting each mail was slow
  • Deleting mails which I had forwarded where the thread was collapsed was FAST (i.e. almost immediate).

This leads me to believe that it's the HTML loading / processing / rendering which is slow, not TB itself or the IMAP interaction. This is on a Lenovo Carbon X1 Gen9 (2 years old) Laptop with plenty of memory and no load.

In that case, this sounds like Bug 1875103 - Deleting or moving a message from the message list pane, message preview for next message is slow, up to 2 minutes to appear. Progress bar is in "indeterminate" state. This may have gotten worse in version 115.

You didn't see this in version 102?

Component: Networking: IMAP → Mail Window Front End
Flags: needinfo?(lohner)
Product: MailNews Core → Thunderbird
See Also: → 1875103
Summary: Large (IMAP?) mails slow to delete → slow to delete email when next message has html newsletter
Whiteboard: [needs protocol log]

Pre-supernova it was fast, only since TB115 it slowed down.
Thanks for the link to the other bug, I just discovered the profiler through the link https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance - that looks awesome and extremely helpful!!

Here is my profile upload: https://share.firefox.dev/3wGev5b
I started the capture, and deleted about 30-40 mails, all HTML newsletters in the 120-250Kb range. All were already downloaded, some were read, most unread. Let me know if this shows anything...

Update: in 115.9.0 it appears to be fast(er). Somewhere between .5 and .6 something seems to have improved. I will keep an eye on it... all mails were downloaded and TB had been open for a while. Maybe its slow with non-downloaded mails, will check and report back.

115.9.0 it appears to be fast(er)

Here is my profile upload: https://share.firefox.dev/3wGev5b
I started the capture, and deleted about 30-40 mails, all HTML newsletters in the 120-250Kb range. All were already downloaded, some were read, most unread. Let me know if this shows anything...

The majority activity is nsViewManager, Paint and webrender, which puts it in the company of these https://mzl.la/3UVzkDq

Does it help to turn off the Status Bar at the bottom of the screen - View/Toolbars/untick Status Bar? (from bug 1875103)

Flags: needinfo?(lohner)
Keywords: dupeme
Summary: slow to delete email when next message has html newsletter → slow to delete email when next message has html newsletter with high activity in sViewManager, Paint and webrender

No, status bar on or off makes no difference. I deleted about 100 mails, half with and half without, and it was the same speed. It's anything with HTML it seems, even with small HTMLs (text with a small table, ~10-15kb size).

Flags: needinfo?(lohner)

Another update. I started using my Ubuntu box again (its on the same wired network where the Win11 Laptop I usually use is, the laptop is on a wired connection via a Thunderbolt docking station), and TB is perfectly fast there, so it's not the server.

So it looks like this:

  • Ubuntu 24.04 (desktop, older machine), TB 115.12.0 64 bit (Snap install) - normal fast deletion of HTML emails (100-200kb size)
  • Win11 Laptop (Lenovo Carbon X1 Gen9) TB 115.12.2 - slow as usual. Both with the 100-200kb mails, also with 10kb mails that just contain a simple HTML table

@Wayne, is there anything else I can profile on the Laptop to narrow this down besides the profile I created above? Or do the same on the Ubuntu machine to compare?

Flags: needinfo?(vseerror)

Thanks for asking. Nothing else to do, until 128 becomes available to see if it reproduces there as well.

Flags: needinfo?(vseerror)
Whiteboard: [has performance profile]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: