Bugzilla

Something's not clear (to me) here. Is the reporter deleting messages from Inbox to Trash or emptying Trash folder? The summary description says the problem occurs when "...deleting hundreds of messages from Trash folder..." Should this actually say "...deleting hundreds of messages **to** the Trash folder..."?

Anyhow, assuming the reporter means "deleting to trash folder", what I describe at  bug 1834056 comment 5 is exactly what the reporter sees. The more messages you are trying to move to trash, the longer it takes and the more memory TB consumes in preparing the single imap "move" command that does the transfer. If you select 1000's of emails to delete into trash, all your physical memory can be consumed and TB crashes for lack of memory. (TB mozilla framework doesn't seem to use any "swap" memory and there is plenty of that left, at least on my system.)

I don't know when this high memory consumption started but with a 110 daily I still have available to run (pre-SN), it doesn't happen and it doesn't happen with 102 release. However, even with those version, I see the deletion taking longer depending on the number of messages being deleted. If I try to delete a lot of messages like 30,000, it also takes a while to prepare the imap command and CPU usage is actually higher than with the current daily, but memory usage (per linux "top") remains constant and about 7% and never goes up and the UI doesn't respond. Once the imap command is built and sent, the UI responds again and the time to complete the move to Trash is mostly due to the imap server doing the moves to Trash internally and after maybe a few minutes reports back an OK response the imap move command.

Something's not clear (to me) here. Is the reporter deleting messages from Inbox to Trash or emptying Trash folder? The summary description says the problem occurs when "...deleting hundreds of messages from Trash folder..." Should this actually say "...deleting hundreds of messages **to** the Trash folder..."?

Anyhow, assuming the reporter means "deleting to trash folder", what I describe at  bug 1834056 comment 5 is exactly what the reporter sees. The more messages you are trying to move to trash, the longer it takes and the more memory TB consumes in preparing the single imap "move" command that does the transfer. If you select 1000's of emails to delete into trash, all your physical memory can be consumed and TB crashes for lack of memory. (TB mozilla framework doesn't seem to use any "swap" memory and there is plenty of that left, at least on my system.)

I don't know when this high memory consumption started but with a 110 daily I still have available to run (pre-SN), it doesn't happen and it doesn't happen with 102 release. However, even with those version, I see the deletion taking longer depending on the number of messages being deleted. If I try to delete a lot of messages like 30,000, it also takes a while to prepare the imap command and CPU usage is actually higher than with the current daily, but memory usage (per linux "top") remains constant and about 7% and never goes up and the UI doesn't respond. Once the imap command is built and sent, the UI responds again and the time to complete the move to Trash is mostly due to the imap server doing the moves to Trash internally and after maybe a few minutes reports back an OK response to the imap move command.