Open Bug 47645 Opened 24 years ago Updated 1 year ago

speed up repetitive "delete,delete,delete" performance

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Type:
defect

Tracking

(Not tracked)

People

(Reporter: scottputterman, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [needs protocol log]) 

Currently if you hit delete over and over again when deleting messages it spends
time trying to load each message and finding the next one to select.  Hyatt says
there's a way to get notified by the tree when we really should be doing this
that he used in keyboard navigation of the tree. We should do this for delete.
Keywords: nsbeta3, perf
Whiteboard: [nsbeta3+]
QA Contact: lchiang → esther
moving to M18.
Target Milestone: --- → M18
sceond pass: - per mail triage
Whiteboard: [nsbeta3+] → [nsbeta3-][cut 8/28]
reassiging to sspitzer
Assignee: putterman → sspitzer
Keywords: mail1
QA Contact: esther → stephend
clearing milestone, m17 and m18 are meaningless now.  these need to be triages
along with the rest.
Target Milestone: M18 → ---
I've created bug 63759 which is a performance tracker bug for mail/news.

marking nsbeta1+ and moving to mozilla0.8
Keywords: nsbeta3 → nsbeta1
Priority: P3 → P2
Whiteboard: [nsbeta3-][cut 8/28] → [nsbeta1+]
Target Milestone: --- → mozilla0.8
clarification of the summary.
Summary: Need to speed up how long it takes to delete messages quickly → Mail message delete performance
accepting.

two things we are working on for this:  using the tree batching api, and not
starting and stopping the throbber on every message.
Status: NEW → ASSIGNED
It might be interesting in looking at what this bug was originally filed for as
well.  Hyatt once told me about a time that he's using for the arrow keys so
that arrowing down doesn't load each message. This could also be useful for
doing fast deleting.
putterman's suggestion may be fixed as simply as changing onselect= to
ontimerselect=
my comment was for multiple delete performance, not for single message delete. 
(I added it to the wrong bug.)

I'll investigate the original issue.
ok, we are definitely calling ThreadPaneSelectionChange() too many times on a
multiple delete.  (once per message we delete!)

using lxr, I don't see ontimerselect.  has it changed names?

suppressOnSelect looks promising..
actually, for multiple deletes, this can be handling in our on js.

there are two problems:  multiple delete and pressing delete a bunch of times.

I'm testing a potential fix for the first one.
Summary: Mail message delete performance → Mail message delete performance: only call ThreadPaneSelectionChange() when we need to.
ontimerselect might be wrong. But it's something like that. suppressOnSelect
might be another neat feature, but unrelated to the timer select thingy.
updating summary, to reflect what this bug was intended to track.

I'll go log a new bug on the calling ThreadPaneSelectionChange() and calling
updatingCommands() too much.

still looking for info on onselecttimer / ontimerselect
Summary: Mail message delete performance: only call ThreadPaneSelectionChange() when we need to. → speend up "delete,delete,delete" performance
fix typo.
Summary: speend up "delete,delete,delete" performance → speed up "delete,delete,delete" performance
note to self:  hyatt pointed me to timedSelect in treeBindings.xml
moving to mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
marking nsbeta1- and moving to future milestone. Though, if this managed to get 
fixed in the thread pane rewrite, that would be great.
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [nsbeta1+] → [nsbeta1+ 2/21]
Target Milestone: mozilla0.9 → Future
nom nscatfood, seems like something real users would do.  If the perf branch
fixed this, maybe we can close it soon :-)
Keywords: nsCatFood
My platform is Linux (RH6.2) -- and when trying to clean up mailboxes
(especially lists), I would like to select at least a few hundred messages (out
of thousands) and delete them.  The performance is so egregiously poor, that I
am lucky to get any decent behavior by deleting messages in blocks of 50-150. 
This is not helping me reduce the size of the 2900+ box that grew while I was
away from home for a few days ...  I've seen this problem in 0.9, 0.9.2, and now
0.9.3.  I wish I could easily convert all these mailboxes back to Netscape 4 (or
even Pine, or K-Mail or ...)

I just deleted a good 7020 messages in just about 14 seconds.
This operation seems to be handled batchly now. Just no need to show all the
mails deleted. Just need to show the mail to be selected after this operation.
I test this on Win2K with more than 1000 mails.
This seems fixed to me with the batch-delete stuff checked in.
But this bug seems to be about the case where the user never deletes one mail at
a time for many mails by pressing the delete key. I think that is a common way
for normal people to delete mails, even when there's 20-30 mails to delete.
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Status: ASSIGNED → NEW
Also, if you hold down the delete button (seamonkey 1.0) to delete messages, eventually it loses track of where it was and even though you're still holding down the delete button, it fails to select a new message and will not delete all of them.  you then have to click another message and hit delete again to get the process started again.  there should be some way to keep track of which message is the next to go to after you delete, that doesnt "get lost" in the case of holding down the delete button.  if this doesnt happen for you, goto control panel (this is windows xp) and speed up the keyboard repeat rate.  maybe it should not refresh the pane until the delete button is released? anyway i'll let you all figure that part out... =) peace
The losing of focus on delete has been fixed on the trunk and the 1.8 branches, iirc. see bug 183394. 
This isn't just a  performance problem for multiple deletes. Sometimes it's a problem for a single delete. In my case, when connecting to a slow IMAP server moving a message to the Trash can take several seconds, even a minute on occasion. 

What's necessary here is magic, and I'm not kidding. Magic is the act of making the viewer think one thing is happening when in reality something very different is going on. What you need to do here is change the local view immediately when the user presses delete, *before the server has responded.* A separate thread out of the view of the user can then go ahead and actually delete the message.

If for some reason the server doesn't delete the message, then it can be restored to the view of the user's inbox later; but this is a rare occurrence. Frankly I might not even bother telling the user the delete failed.

For more on the concept of magic in programming and user interfaces see http://www.asktog.com/columns/069ScottAdamsMeltdown.html
Depends on: 22102
QA Contact: stephend
Should this be "core"? I would think Thunderbird could also use this improvement.
Product: Core → MailNews Core
Assignee: mail → nobody
Component: MailNews: Main Mail Window → MailNews: Backend
OS: Windows NT → All
Priority: P2 → --
Product: Mozilla Application Suite → Core
QA Contact: backend
Target Milestone: Future → ---
Has someone tested this recently on trunk and a) can say the problem is gone or b) has the technical details to move this bug forward?

Otherwise, lack of nomination for TB3, and no one stepping forward to do this means nothing will happen until after Thunderbird 3. Which may be a good thing - because a combination of bugs some already fixed and some in progress may help this,  plus there's a lot of UI change happening in TB3.
Summary: speed up "delete,delete,delete" performance → speed up repetitive "delete,delete,delete" performance
Just wondering if this is slated to be fixed in Thunderbird 3 or not. I can't quite tell based on some of the feedback. It is certainly a problem. Is Scott Putterman still around?
Looks like this is still an issue.
Blocks: 437443
Still a bug for you?
Flags: needinfo?(scottputterman)
Flags: needinfo?(scottputterman)
Whiteboard: [nsbeta1+ 2/21] → [needs protocol log]
Severity: normal → S3

WONTFIX?

Duplicate of this bug: 437443
You need to log in before you can comment on or make changes to this bug.