18708 - We need to look into optimizing operations like mark all as read

Status: VERIFIED DUPLICATE of bug 17470

(MailNews Core :: Backend, defect, P3)

Description

[Scott MacGregor]

I know Phil or someone else mentioned this before. But we need to look into
optimizing operations like mark all as read.


I just opened a netscape.public.mozilla.builds which I hadn't read in two weeks
(i get the email version =)), and marked 900 messages as read.


It took about 40 seconds to do with a release build on my machine. That
time may be okay, but we also starved out the UI when we did it so the app
basically froze for the 40 seconds which isn't okay.


I suspect the optimizations to do this will hit lots of people...
1) is the rdf command marking each message as read individually or
does it support batch commands on a large selection?
 (putterman?)

2) is the news db layer properly managing the db for each action. i.e.
are we flushing the db each time we mark a message as read? Are we properly
batching all the commands in the db layer before we do that final commit?
(sspitzer?)

Who wants to start with this bug? I guess I'll start with Scott P. to help
us answer question (1)....

Comment 1

[scottputterman]

this is a slow operation whether mail or news.  I'm sure it's all in RDF. It
will eventually be worked on.

Comment 2

[(not reading, please use [e-mail] instead)]

I think the news db may be doing a commit way more often then necessary.

a while back, we weren't calling commit on close of the news db, because the
refcount never got zero.

that got fixed, but I never took out the extra commits.

I'll go do that now.

bienvenu thinks the real performance hit isn't UI, or the db, but rdf.

he's mentioned that batching is the way to fix it.

adding him to the cc list.

Comment 3

[(not reading, please use [e-mail] instead)]

I take it back, the nasty extra commits got remove a while back.

Comment 4

[Phil Peterson]

*** This bug has been marked as a duplicate of 17470 ***

Comment 5

[laurel]

Verified as a duplicate.