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

VERIFIED DUPLICATE of bug 17470

Status

P3
normal
VERIFIED DUPLICATE of bug 17470
19 years ago
10 years ago

People

(Reporter: mscott, Assigned: scottputterman)

Tracking

Trunk
x86
Other

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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)....
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 1

19 years ago
this is a slow operation whether mail or news.  I'm sure it's all in RDF. It
will eventually be worked on.
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.
I take it back, the nasty extra commits got remove a while back.

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 4

19 years ago
*** This bug has been marked as a duplicate of 17470 ***

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 5

19 years ago
Verified as a duplicate.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.