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)....
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 17470 ***
Verified as a duplicate.
You need to log in before you can comment on or make changes to this bug.