Closed Bug 1116794 Opened 10 years ago Closed 9 years ago

deleting multimple individual mails is slow

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Version:
31 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 47645

People

(Reporter: roland.illig, Unassigned)

Details

(Keywords: perf) 

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140923175406

Steps to reproduce:

I received 10 new mails from a POP3 account, saving them in my local spam folder (which contains 1700 mails). These mails are all spam, so I want to delete them quickly. To do this I select the first mail and then press the Delete key quickly for 10 times.


Actual results:

I can watch the mails being deleted one by one, each taking about 0.5 seconds. This means after typing I have to wait for 4 seconds.

Only the first of the 8 mails have been deleted. The remaining 2 are still there.


Expected results:

All 10 mails should have been deleted. Deleting 10 mails should not take 5 seconds, but only as long as I need for pressing the Delete key.
1. Is this spam folder the "Junk" folder?  If so, just right click on Junk and do Empty.
2. What antivirus software are you using?  Is deleting much faster with it disabled?
Flags: needinfo?(roland.illig)
Whiteboard: [closeme 2015-03-01]
1.

This spam folder may be the junk folder or some other folder, the problem happens everywhere. Clearing the whole folder is not an option, since I want to delete the mails selectively. Another use case is when I want to cleanup my inbox from some lengthy discussions, but keep other important mail.

2.

The problem still exists if I disable any and all antivirus software. There is no noticeable difference in speed.
Flags: needinfo?(roland.illig)
Whiteboard: [closeme 2015-03-01]
Even though "select 8 mails which you want to delete + single delete" is usual or normal or ordinal operation, why you want to do action like "press delete key pretty quickly multiple times"?

Thread pane consists of TreeView of Mozilla family.
   each row == treeitem, and associated messageKey is held in XUL element for each "treeitem"
   "Delete of a selected mail at Tread pane by pressing delete key" 
      = invoking "Delete key event handler ssociated to the treeitem element
         !=== invoke delete of mail of messageKey==nnn which is shown at the row when you pressed delete key
   (a) Selected trritem=row at Thred pane when delete is pressed ->  associated messageKey of mail
   (b) Association change(to mail shown at second row) at a row(treeitem located at top) due to delete of previously shown mail
   are executed concurently, and, needless to say, each takes at least a while.
   (i) While "(a) + (b) " is repetedly being executed, if delete key is pressed many times,
        "Delete even t handler" may use messageKey of other mail(previously shown one or next one).
   (ii) "Multiple delete key press at a row for a mail" may be counted as "one" because it's "delete mail operation".
   In these cases, (i) can be called "timing hole", but (ii) is pretty normap phenomenon,
   if delete key is pressed while processing delete key press at top row for a mail, before mail at next row(2nd tow) is completely shown at top tow.
Because phenomenon is "8 mails were deleted by 10 delete key press, 2 remained", I suspect phenomeno like (ii).
i.e. Key press can be ignored, if too quickly pressed multiple times.

A workaround :
   Use Shift+Delete if you want to request "Delete" multiple times, very quickly, repetedly.
   Because confirmation dialog is shown by Tb, you can't press delete so quickly multiple tmes :-) 

To analyze problem, at leasy following is needed.
  - Hook "invoking delete key event handler at tree row 0", and check associated messageKey.
  - Hook "delete of msgDBHdr at the folder"
Both are possible by AddEventListener for teeeitem(top row only is sufficient in this case) and msgFolder. "Key event for Delete at ThredPane" may be needed in case of "delete event handler is disabled at treeitem by delete key press".
> Bug summary : deleting mails is slow

FYI.

By single mail delete, following is executed. (ssume local mail folder)
   Cehck associated messageKey of selected mail (top row in your case)
   Copy mail to Trash folder8crete mgDBHdr, red mil data in Inbox, append mail data to file named Trash, update msgDBHdr data.
   At Inbox, write "deleted flag" to X-Mozilla-Status: header line in file named Inbox, remove msgDBHdr.
   Updaate count of Inbox and Trash.
   Refresh Folder Panem, if Inbox and Trash is shown at Folder pane and unread count is modified.
   Updte Thread Pne display of Inbox. Shift assciated mil data to each treeitem.
   Updte Thread Pne display of Trash if Trash is shown at Tab or other messenger window.
 . Shift assciated mail data to each treeitem Inbox, and refresh Thread Pane.
.  Shift assciated mail data to each treeitem Trash and Thread Pane, if Trash is shown some where..
Above is executed for each mail by your favarite operation.
To bug opener:
Do you think "10 consecutive Delete key press when a mail is selected at top row of Thread Pane"
            === request of "Delete 10 consecttive mails which are shown at row 0 to row 9 of Thread Pane"?
If so, it's wrong.
      "10 consecutive Delete key press when a mail is selected at top row of Thread Pane"
      === 10 consecutive requests to treeitem at row 0(a box, similar to DIV of HTMlL) to do "invoke delete key event handler associated to this box"
When one delete key press is processed, process of "delete a mail currently shown at row 0" is started". Time requred to complete the "delete a mail currently shown at row 0" is never ZERO. If next "Delete key press" occurred while the "delete a mail currently shown at row 0 by previous Delete key press" is in progress. result is timinig dependent.
This is because current implementation is "Event driven".
If implementation you want, design like following is neeeded.
    You press Delete 10 times -> treeitem puts 10 Delete key press events in a Queue 
    ->   Tb's  message request processor : Do While(0<number of requests in Queue){ execute  request; when process completed, read next request; }
I don't think this kind of implementation is approprite for prosess of event like key press, mouse move/down/up etc. or menu click.
This kind of implementtion is usually used for process at higher level:. For example,
     Multiple requests to an IMAP mbox by multiple tasks at same time.
           User requests fetch of mail in Inbox for mail viewing. At same time, message filter requests mail move from Inbox by filtering. 
     To serilize multiple requests to Inbox, requests are placed in Queue, and each request is executed serially.
To bug opener: Do you use Tb's profile directory on file share server?
If so, "copy mail data from file named Inbox to file named Trash(read from Inbox, append to Trash)" step takes longer than you expect.
   When "write to Trash", "API level write" is requested for each line of message source.
   Because of mail,  "a line" is usually around 80 bytes. So, "write" is requested "mail size/80" times. See Bug 769346.
   If local HDD, performance issue is usually not exposed because OS's buffering/Disk Cache works.
   However, if file share, and if big mail, performance issue may be exposed.
   If Virus Scan of AV software is enabled for file named Trash by you, it's miserable.
(In reply to WADA from comment #3)
> Even though "select 8 mails which you want to delete + single delete" is
> usual or normal or ordinal operation, why you want to do action like "press
> delete key pretty quickly multiple times"?

Imagine your inbox to look like this:

1. email from automatic monitoring
2. email from automatic monitoring
3. email from automatic monitoring
4. personal mail from a human
5. email from automatic monitoring

When I see this, I know what to do: Delete, Delete, Delete, Down, Delete, and that’s exactly what I type.

Imagine the inbox contains a little more mails, and you have the scenario from the original bug report.

In Microsoft Outlook this works like a charm and is really fast, therefore I miss this behavior in Thunderbird.


(In reply to WADA from comment #5)
> To bug opener:
> Do you think "10 consecutive Delete key press when a mail is selected at top
> row of Thread Pane"
>             === request of "Delete 10 consecttive mails which are shown at
> row 0 to row 9 of Thread Pane"?
> If so, it's wrong.
>       "10 consecutive Delete key press when a mail is selected at top row of
> Thread Pane"
>       === 10 consecutive requests to treeitem at row 0(a box, similar to DIV
> of HTMlL) to do "invoke delete key event handler associated to this box"

Whatever the exact implementation is, it does not match my expectation as a naive user. Imagine a word processor that worked according to this argument. Would you ever like to use that?

> When one delete key press is processed, process of "delete a mail currently
> shown at row 0" is started". Time requred to complete the "delete a mail
> currently shown at row 0" is never ZERO. If next "Delete key press" occurred
> while the "delete a mail currently shown at row 0 by previous Delete key
> press" is in progress. result is timinig dependent.
> This is because current implementation is "Event driven".

An acceptable solution (at least to me) would be to make the Delete operation take less time. It seems to me that currently the operation involves (as you said):

1. add a copy of the mail to the Trash folder
2. mark the mail in the Inbox folder as deleted
3. remove the current TreeItem from the tree view
4. display the now current mail in the mail window

Steps 1 to 3 are necessary, but step 4 should be executed in the background. If possible, step 3 should be executed before step 1. (Since step 3 only affects the screen view of the Inbox folder, nothing bad would happen in case the computer is shut off between step "remove" and "mark".)


(In reply to WADA from comment #6)
> To bug opener: Do you use Tb's profile directory on file share server?

No, it’s on a local disk, which is a traditional rotating disk with access times in the tens of milliseconds range.

>    When "write to Trash", "API level write" is requested for each line of
> message source.
>    Because of mail,  "a line" is usually around 80 bytes. So, "write" is
> requested "mail size/80" times. See Bug 769346.

Ouch. That’s not what I would expect. Nice to know.
(In reply to Roland Illig from comment #7)
> Row #0 : mail 1. email from automatic monitoring
> Row #1 : mail 2. personal mail from a human
> Row #2 : mail 3. email from automatic monitoring

If operation is quicly done, I think following occur, if "Delete of a mail + Thread pane refresh" is slow.
   When Row #0 is selected, press Delete(-> delete mail 1 is started) -> Press Down Arrow key -> Selected mail is Row #1/ mail 2
   -> Delete of mail 1 ends -> top is Row #0 : mail 2 -> Press Delete -> delete is started for mail 2 ...
Right?
(In reply to WADA from comment #8)
> (In reply to Roland Illig from comment #7)
> > Row #0 : mail 1. email from automatic monitoring
> > Row #1 : mail 2. personal mail from a human
> > Row #2 : mail 3. email from automatic monitoring

> If operation is quicly done, I think following occur, if "Delete of a mail +
> Thread pane refresh" is slow.
>    When Row #0 is selected, press Delete(-> delete mail 1 is started) ->
> Press Down Arrow key -> Selected mail is Row #1/ mail 2
>    -> Delete of mail 1 ends -> top is Row #0 : mail 2 -> Press Delete ->
> delete is started for mail 2 ...

This shouldn’t happen. Instead, the following should happen:

function onDelete() {
  var selectedNodes = treeView.selectedNodes();
  treeView.hide(selectedNodes);
  treeView.refresh();
  
  background.schedule(function() {
    mailPane.refresh();
  });

  background.schedule(function() {
    selectedNodes.moveMailsTo(trashFolder);
  }, {priority: 'low'});
}

This way, the list of mails is updated as fast as possible. Then comes the mail pane, and only then is the mail moved to the Trash folder. This follows the general principle that the UI should react fast to the user actions.
(In reply to Roland Illig from comment #9)

Thanks for explanation about current mechanism.
If so, at which step slowness in "delete multiple mails by delete + down arrow + delete + ..." observed?
1. Press first delete -> top row is hidden, then thread pane is refreshed -> next mail is placed at top, delete is invoked at back ground
2. Press delete or arrow -> Thread pane is updated according to pressed key, and if delete, delete is invoked at back ground
3. Repeat 2

If "select multiple mils at Thred pane + single Delete key press", what knid of slowness do you see?
Is "Move multiple mails from Inbox to Trash is pretty slow" observed?
How about manual "Copy multiple mails from Inbox to Trash"?
(In reply to WADA from comment #10)
> (In reply to Roland Illig from comment #9)
> 
> Thanks for explanation about current mechanism.

I didn’t explain the current mechanism at all. I just suggested a new one.

I think the slow steps are copying the mail and displaying the next mail in the mail pane. That’s why I suggested to execute these steps in the background.

> If "select multiple mils at Thred pane + single Delete key press", what knid
> of slowness do you see?

Since all steps are executed in one large batch, I cannot say which of them is slow. But one thing: when I select a mail and then Shift+click to select 20 mails, it takes about one second until all the mails are displayed as selected. Another few tenths of a second later, the mail pane displays a summary of all selected mails.

> Is "Move multiple mails from Inbox to Trash is pretty slow" observed?

Yes.

About 0.3 seconds after pressing Delete, all 20 selected mails are marked as read.
About 1.6 seconds after pressing Delete, the 20 selected mails are gone.

> How about manual "Copy multiple mails from Inbox to Trash"?

This also takes some time, which is ok. But selecting the mails should be faster. It takes about 0.7 seconds after the Shift+click.
(In reply to Roland Illig from comment #11)
> But selecting the mails should be faster. It takes about 0.7 seconds after the Shift+click.

This is known issue. See bug 778907, bug 847455, bug 943116, bug 975795 and bugs listed in dependency tree for these bugs.
Improved than before, but "showing summary of selected mails" surely takes a while, because it can not be completed within ZERO second.
IIRC, there are two kinds of option setting relevant to it.
(i) Kill excess jobs when multiple mails are selected
     mail.operate_on_msgs_in_collapsed_threads = false
(ii) When "showing summary of selected mails" is used, reduce jobs executed by "showing summay of selected mails".
      mail.show_multiple_message_summaries = false
Other setting is also  relevant to slowness in UI.
(iii) Stop excess jobs for accessibility.
      accessibility.force_disabled = 1

To observe "pure slowness in delete mail", check with mail.operate_on_msgs_in_collapsed_threads = false and accessibility.force_disabled = 1, please.
In mail delete, at least (a) "Read data from file named Inbox on HDD" + (b) "Write data to file named Trash on HDD" is needed.
And, following is always true.
   "time for (a)" + "time for (b)" < "time required to delete a mail in Tb"
To know "time for (a)" + "time for (b)", Process Monitor is useful.
How long does it take for (a) + (b) in your environment?
   IIRC, for (a), "Read with 4KB block in binary mode(not line mode)" is used, and for (b), "Write a data line(same as Line mode write)" is used.
(In reply to Roland Illig from comment #11)
> > Is "Move multiple mails from Inbox to Trash is pretty slow" observed?
> Yes.
> About 0.3 seconds after pressing Delete, all 20 selected mails are marked as read.
> About 1.6 seconds after pressing Delete, the 20 selected mails are gone.

"2 seconds to delete(==move to Trash folder) 20 mails" is so slow for you or for your environment?

How about "Shift+Delete of 20 selected mails"?
  <------------------- exclude time for this ---------------------------><--- time for this --->   
  Select 20 mails -> Shift+ Delete -> Dialog is shown -> reply Delete -> delete is executed
(In reply to WADA from comment #12)
> (In reply to Roland Illig from comment #11)
> > But selecting the mails should be faster. It takes about 0.7 seconds after the Shift+click.
> 
> This is known issue. See bug 778907, bug 847455, bug 943116, bug 975795 and
> bugs listed in dependency tree for these bugs.
> Improved than before, but "showing summary of selected mails" surely takes a
> while, because it can not be completed within ZERO second.

Even when I switch off the mail pane, selecting several mails is still slow.

> IIRC, there are two kinds of option setting relevant to it.
> (i) Kill excess jobs when multiple mails are selected
>      mail.operate_on_msgs_in_collapsed_threads = false
> (ii) When "showing summary of selected mails" is used, reduce jobs executed
> by "showing summay of selected mails".
>       mail.show_multiple_message_summaries = false
> Other setting is also  relevant to slowness in UI.
> (iii) Stop excess jobs for accessibility.
>       accessibility.force_disabled = 1
> 
> To observe "pure slowness in delete mail", check with
> mail.operate_on_msgs_in_collapsed_threads = false and
> accessibility.force_disabled = 1, please.

I tried it with mail.operate_on_msgs_in_collapsed_threads = absent and accessibility.force_disabled = 1, and it’s still as slow as before.

(In reply to WADA from comment #13)
> In mail delete, at least (a) "Read data from file named Inbox on HDD" + (b)
> "Write data to file named Trash on HDD" is needed.
> And, following is always true.
>    "time for (a)" + "time for (b)" < "time required to delete a mail in Tb"
> To know "time for (a)" + "time for (b)", Process Monitor is useful.
> How long does it take for (a) + (b) in your environment?
>    IIRC, for (a), "Read with 4KB block in binary mode(not line mode)" is
> used, and for (b), "Write a data line(same as Line mode write)" is used.

Ouch. For 20 mails, there are really about 10000 system calls WriteFile("Trash", buffer, 78). And of course, this takes its time. 0.8 seconds on my computer.



(In reply to WADA from comment #14)
> (In reply to Roland Illig from comment #11)
> > > Is "Move multiple mails from Inbox to Trash is pretty slow" observed?
> > Yes.
> > About 0.3 seconds after pressing Delete, all 20 selected mails are marked as read.
> > About 1.6 seconds after pressing Delete, the 20 selected mails are gone.
> 
> "2 seconds to delete(==move to Trash folder) 20 mails" is so slow for you or
> for your environment?

Yes, I consider this slow. Today, I compared it again to Microsoft Outlook, and there I even dared to hold down the Delete key and watch the mails disappear. At this time, I don’t trust Thunderbird that it would stop deleting mails after I release the Delete key.

> How about "Shift+Delete of 20 selected mails"?
>   <------------------- exclude time for this ---------------------------><--- time for this --->   
>   Select 20 mails -> Shift+ Delete -> Dialog is shown -> reply Delete -> delete is executed

This still takes about 1.0 second in the UI. The actual disk access (20 reads à 4096 bytes, 20 read à 22 bytes, 20 writes à 22 bytes) finishes in rapid 0.05 seconds.
(In reply to Roland Illig from comment #15)
> I tried it with mail.operate_on_msgs_in_collapsed_threads = absent (snip) and it’s still as slow as before.

Absent at where? in prefs.js file? Or at Config Editor panel? (Tools/Optiona/Advanced/General, Config Editor, if Win)
Default of mail.operate_on_msgs_in_collapsed_threads=true, so "absense of it it in prefs.js" means you set it to true. 
Do Toggle at Config Editor.

> > How long does it take for (a) + (b) in your environment?
> >    IIRC, for (a), "Read with 4KB block in binary mode(not line mode)" is
> > used, and for (b), "Write a data line(same as Line mode write)" is used.
> 
> Ouch. For 20 mails, there are really about 10000 system calls WriteFile("Trash", buffer, 78).
> And of course, this takes its time. 0.8 seconds on my computer.

Half of "time required to delete a mail" is "copy mail data from file named Inbox to file named Trash".

> > How about "Shift+Delete of 20 selected mails"?
> >   <------------------- exclude time for this ---------------------------><--- time for this --->   
> >   Select 20 mails -> Shift+ Delete -> Dialog is shown -> reply Delete -> delete is executed
> 
> This still takes about 1.0 second in the UI. 
> The actual disk access (20 reads à 4096 bytes, 20 read à 22 bytes, 20 writes à 22 bytes) finishes in rapid 0.05 seconds.

Shift+Delete == Delete without move mail data to Trash.
"Physical accessed to HDD" is rewrite of "Deleted status flag in X-Mozilla-Status: header".
"Delete mails" - "copy mail data to Trash" =
          (a) "add msgDBHdr for new mails in Trash"     + (b) "remove msgDBHdr at Inbox for moved mails to Trash"
      + (c) "UI refresh for Inbox(move source folder)" + (d) "UI refresh for Trash(move target folder)"
      If Sihift+Delete, no need to do (a) / (d).
      When "Delete mails", Inbox is currently shown at Thread Pane. So, "Refresh of Thread Pane" occurs on Inbox only. 
So, your test result of Shift+Delete = (b) + (c) took 1.0 sec.

In your case, a half of "time to delete mails" = Copy mail data from Inbox to Trash, and another half = above (a) + (b) + (c) + (d) .

By the way, "Time to delete n mails" is approximately/roughly "K +  n * P",  where K = cost per one delete operation, and P = cost per one mail.
   Delete 1 mail * n times : n * { K + (1 * P) } = ( n * K ) + ( n + P )
   Delete n mails          : K + (n * P), but currently, it's "S + K + (n*P)" where S = cost to select n mails, and S is sufficiently large :-)
FYI.
Bug 452221 is an example of "job of (b) and jobs by (b)" takes long. 
There two kinds of known issues;
   (i)  Bug 452221 : Updating Thread structure data.takes long.
   (ii) Preparation work for "Undo Delete" is expensive.
Both are already improved than before, but issue of "expensive" or "takes time" still remains.
Some of issues are problem of inefficiency in code : O( n ^ 2) like one instead of O( n ) .
But others are : code is O( n ) or O( n * log(n) ), but it's O( K * n ) or O( K * n * log( Q * n) ) like one, and constant K, Q are pretty large.
(In reply to WADA from comment #16)
> (In reply to Roland Illig from comment #15)
> > I tried it with mail.operate_on_msgs_in_collapsed_threads = absent (snip) and it’s still as slow as before.
> 
> Absent at where? in prefs.js file? Or at Config Editor panel?

Yes, absent in prefs.js. But it exists in the Config Editor panel. I hadn’t expected that.

> (Tools/Optiona/Advanced/General, Config Editor, if Win)
> Default of mail.operate_on_msgs_in_collapsed_threads=true, so "absense of it
> it in prefs.js" means you set it to true. 
> Do Toggle at Config Editor.

I did that, and no matter whether it is true or false, the speed is the same.

----

At this point, there are 2 things that are slower than necessary:

1. writing mail to disk in chunks of 78 bytes. It should really be possible to buffer that data and then call fflush() at the end.
2. displaying the list of mails in the thread pane. This affects selecting multiple mails, deleting mails, navigating between mails.

How can we proceed to fix them? I’m not interested in more technical details, I just want Thunderbird to be reasonably fast. Not lightning fast, just reasonably.
First - thanks very much for your interest in this area. These reports are helpful for improving Thunderbird.

(In reply to Roland Illig from comment #18)
> At this point, there are 2 things that are slower than necessary:
> 
> 1. writing mail to disk in chunks of 78 bytes. It should really be possible
> to buffer that data and then call fflush() at the end.
> 2. displaying the list of mails in the thread pane. This affects selecting
> multiple mails, deleting mails, navigating between mails.
>
> How can we proceed to fix them? 

a) are you offering to help fix?

b) no doubt you have read the bugs

b1) (however, what you may not get from the bugs is...) Fixing the buffering (bug 769346 is one) will be a huge improvement that we very much need. And ISHIKAWA is on that, but there may be long gaps between updates in that bug in part because we currently plan to first improve IO error checking, before actually touching buffering.

b2) To better assist in improving Thunderbird performance you will want to be able to more accurately assess the current state of what is not yet fixed.  To do that you must run one of the branches other than the public release - beta (currently version 36, soon to be 37) or Earlybird (currently version 37) [1], or Daily (currently version 38) [2]. For example, two of the bugs mentioned in comment 12 are fixed and the improvment available in beta - these are huge improvements. 

[1] http://www.mozilla.org/en-US/thunderbird/channel/
[2] http://download-origin.cdn.mozilla.net/pub/mozilla.org/thunderbird/nightly/latest-comm-central/
Keywords: perf
(In reply to Roland Illig from comment #18)
> (In reply to WADA from comment #16)
> > Default of mail.operate_on_msgs_in_collapsed_threads=true, so "absense of it
> > it in prefs.js" means you set it to true. 
> > Do Toggle at Config Editor.
> I did that, and no matter whether it is true or false, the speed is the same.

What's speed is same? That setting is for "speed of selecting multiple/many mails at Thread Pne". is never ffor "speed of delete of mails" .

> How can we proceed to fix them?

For known bug: 
    If you can propose a patch for bug, do it. If you can not propose patch for bug, wait for "some one will fix the bug". That's all.
For unknown bug : Analyze problem, find cause, find solution, open bug for the problem, wait for bug fix by simeone ncluding you. That's all. :
(In reply to Roland Illig from comment #18)
> How can we proceed to fix them?

Bug 1133721 is for "Shift+Delete of 1 million messages in a folder" case. Plese propose patch at that  bug. If such bug will be fixed and 1 million mails will be deleted at a glance, "delete of 20 mails" will be finished at a glance :-)
(In reply to Wayne Mery (:wsmwk) from comment #19)
> a) are you offering to help fix?

In general yes, but not by coding. And I feel that this bug report already has too many details, preventing anyone from reading it fully, so it might be better to summarize it and open another bug containing only the summary. Shall I do that?
(In reply to Roland Illig from comment #22)
> (In reply to Wayne Mery (:wsmwk) from comment #19)
> > a) are you offering to help fix?
> 
> In general yes, but not by coding. And I feel that this bug report already
> has too many details, preventing anyone from reading it fully, so it might
> be better to summarize it and open another bug containing only the summary.
> Shall I do that?

If you want to do a summary, add it has a comment to this bug, and make a note in the whiteboard pointing to the summary comment as the recommended overview. Do not create a new bug.
Multiple passible causes of slowness are noted. I'm just going to pick one that stands out the most to me, and declare this a duplicate of bug 47645
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Summary: deleting mails is slow → deleting multimple individual mails is slow
You need to log in before you can comment on or make changes to this bug.