1.I selected all 1 million messages in a folder via Ctrl-A. Selecting them took a moment (like 25secs), but that was expected. It is good that it is even possible thanks to bug 778907. 2.Then I used Shift-Delete to remove them without going to trash. Took a while to display a confirmation question (like 40 minutes). But at this stage TB was NOT increasing memory usage, basically NOT using any CPU, only heavily using the disk writing to the mbox file, NOT the .msf file. Which is strange why it would write anything while the delete was not confirmed yet). Only after this writing was finished, the .msf file timestamp was updated so it was probably written to. 3.After confirming the permanent deletion, TB started to work on the actual deletion. That took 3 HOURS (also thanks to some swapping) until finally crashing with "out of memory" errors in console when it hit 3.5GB of RAM usage in a 32bit process (in Linux). I have not tested whether it was still in UI code somehow updating the list of messages or it was already doing the delete in backend (or both). But NOT all messages are marked as deleted in the mbox file (X-Mozilla-Status: 0009) after the crash. It appears to me usually such large amounts of memory are being taken my UI Javascript code, but it is not confirmed.

sort like bug 693659?

Yeah, quite possible.

FYI. If all mails have same subject, and if threading based on subject(not based on references) is used, phenomenon can be observed with not-so-large number of mails. See bug 452221. If "Mark as Junk" or "Mark as not Junk", pretty high memory consumption can be observed at same time when "it takes very long" is observed, with not-so-large number of mails. Several hundreds mails is sufficient. There is no need of "million mails". When bulk move/copy/delete, I believe job should be split to multiple small jobs. move_granularity=XX. Split to N sub-jobs; Do Job#=1 to N; Do job of "move XX mails"; Commit move of XX mails(undo is not supported); End; If Drag, "number of selected mails" should be limited by setting like max_drag_mails=1000, because onDragStart processing is needed.

A profile on a smaller sample size would be useful, say 10,000 messages? https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Thunderbird_Performance_Problem_with_G

TB doesn't like "BIG DATA"... ;)