Closed Bug 49212 Opened 24 years ago Closed 24 years ago

Delete All messages causes a ton of repainting

Categories

(SeaMonkey :: MailNews: Message Display, defect, P1)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: phil, Assigned: Bienvenu)

References

Details

(Keywords: perf, Whiteboard: [nsbeta1+ 2/13]) 

Using 2000-08-16-08 commercial build on NT

1. Open a mail folder with a couple hundred messages. I was using my bugzilla
folder, which had ~300 messages
2. Select all messages
3. Delete

Thread pane repaints at least once for every message, sometimes overpainting. It
took a long time (30-40 secs?) to delete the messages, I assume due to all this
repainting.
Nominate for nsbeta3
Keywords: nsbeta3
this is probably a dup of 17470 given that we update the message counts every 
time a delete occurs just like we do every time we mark a message read.
QA Contact: lchiang → esther
Hmm. I thought Delete All used to be faster. Are we doing something new here?
I'm a little doubtful that it's been this bad since way back around bug 17000.
+ per mail triage
Keywords: mail2
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
I think it's a combination of a couple of things. The first thing is some 
command updating fixes I'm going to checkin by Monday. And the second is because 
of the updating of the counts.  The command updating fix, cut in half the amount 
of time it took me to delete 1000 messages, so hopefully it'll speed up smaller 
folders as well.
my portion of the fix checked in. cc'ing Seth who's watching the tree for me 
tomorrow. And, reassigning to bienvenu for the rest of the fix.  We should 
probably just nsbeta3- the rest of the work on this bug since we will probably 
not get to it for this release.

I believe that when bienvenu checks in that there will be about a 25% savings 
ontop of what I wrote before.
Assignee: putterman → bienvenu
I've checked in my part for imap - it's harder for local messages, ironically, 
because those messages are deleted one at a time and it's harder to do batching. 
If this *does* fix repainting problems, then we have other problems because 
changing message counts shouldn't cause repaints in the thread pane.
I don't actually see repainting. But I think we've cut the time down if half to 
do this operation so I think that's enough for now.  The bug isn't fixed since 
it's still pretty slow, but it's better, so I think we can mark nsbeta3-, which 
I'm going to do.
Whiteboard: [nsbeta3+] → [nsbeta3-]
Status: NEW → ASSIGNED
sorry for the extra email. Removing mail2 keyword.
Keywords: mail2
*** Bug 60430 has been marked as a duplicate of this bug. ***
QA Contact: esther → sheelar
Keywords: mail1
changing priorities
Priority: P3 → P2
according to rjc, the rdf batching api's exist and work.

would that help?  I'm thinking about seeing what batching does for the "getting
next n messages is slow" bug.  

that bug is related to this bug.
yes, if rdf batching is hooked up to tree control/layout batching, then it
should all just work.

nsMsgFolder::EnableNotifications is a method to turn certain notifications on
and off. We could add a notification type for turning on and off rdf
notifications, and when we get that notification type, turn rdf batching on and
off. I'll look into it, and see how it works. 
> yes, if rdf batching is hooked up to tree control/layout batching, then it
should all just work.

Ah... don't expect "rdf batching" to necessarily do what you want/expect it to. 
 In its current form, while its "on" it just ignores all assertions that fire.  
It doesn't "pool" or "coalesce" them... it simply drops them so that the XUL 
template builder doesn't do anything to the content model.
*** Bug 64037 has been marked as a duplicate of this bug. ***
We *didn't* do this for local folders (turn off notifications of folder count
changes) and I think it's very noticeable. I need to figure out how to do
batching for deletes of local messages. It's easy to turn off notifications on
delete, but I need to make sure we turn them back on :-)
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
marking nsbeta1+ and moving to mozilla0.8
Keywords: nsbeta1, perf
Priority: P2 → P1
Whiteboard: [nsbeta1+]
Target Milestone: M18 → mozilla0.8
I've fixed this for local folders as well now (doing batching). 
Is this bug now only about local folders? I'm using IMAP, and it's still pretty
bad with the RTM build.
no, I'm just bringing local folders up to the level that we have for imap
folders. However, I'm not noticing any repainting when deleting all the messages
in an imap folder - it's just painfully slow reflowing in layout on every delete. 
Ok, I see. Is there a separate bug for that?
there are probably lots of bugs about that. I suspect we've made this the one
bug to stand in for all our thread pane delete performance problems.

I think one thing that makes this particularly slow is that if you're sorted by
date, in essence what happens here is that that first message gets deleted over
and over again, as near as the tree control can tell. So, it basically does the
maximum amount of work possible, reflowing the whole thread pane N times where N
is the number of messages in the folder.  To test this, I'll try doing a reverse
sort by order received, and see if delete all is faster.
I'll put this bug in bug 63759, which is our mail/news perf tracker bug.
a related bug would be the "'Get Next 100 News Messages' is slow".

if you are sorted by date, every new news message gets inserted at the top, and
causes us to resort.

I'm working on not relying on rdf to do the sorting for us, which would help
with a bunch of these problems, and some other bugs, like "delete the top
message in a thread causes the thread to jump".

I'll keep you posted.

moving to mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
the two things we are working on that will speed up multiple delete:

1) using the tree batching apis
2) not starting and stopping the throbber for every message (this regressed.)

bienvenu, would you object if I changed the summary so this can be the catch bug
for any multiple delete performance work?
*** Bug 66689 has been marked as a duplicate of this bug. ***
sure, that's fine.
marking nsbeta1- and moving to future.
Whiteboard: [nsbeta1+] → [nsbeta1+ 2/13]
Target Milestone: mozilla0.9 → Future
Keywords: nsbeta1 → nsbeta1-
should be fixed by landing the performance branch. There is still work we can do
to batch updates to the outliner, but we can open a new bug for that.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
verified,
win98-2001-03-23-06
linux-2001-03-26-05
mac-2001-03-23-10
This problem is fixed. I had between 300-400 messages when I deleted messages 
from a local folder and an Imap inbox folder.  The messages were deleted between 
5 to 7 seconds on each machine.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.