Adding/Removing messages using nsIRDFObserver functions is really slow

VERIFIED FIXED in M12

Status

SeaMonkey
MailNews: Message Display
P3
normal
VERIFIED FIXED
19 years ago
9 months ago

People

(Reporter: scottputterman, Assigned: Chris Waterson)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Perf])

(Reporter)

Description

19 years ago
When we add or delete messages using the nsIRDFObserver functions OnAssert and
OnUnassert, performance is really bad and much worse than when just using
GetTargets.

To see this, delete a folder's .msf file, and then restart and click on that
folder.  It will take much longer to load this folder.

This will also affect the time to download new headers - especially in Imap and
News.

See bug 6873 for more useful info as well as various newsgroup postings in the
mail-news newsgroup.
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 1

19 years ago
It ain't wonderful now, but we're back in the game I think.
(Reporter)

Comment 2

19 years ago
I just wanted to point something out.  If you're using Mailnews to test this
then you might be getting some erroneous data.  Currently 10905 is open and says
that when we parse a mailbox only the first 1MB gets read in.  My 1300 message
mailbox takes up 7MB.  So, probably only the first 200 messages are actually
being added and given to RDF.

Also, unless performance is where we want it to eventually be, should we leave
this open?  I think we need a bug to track this.  Or are you saying that this
makes the async case equivalent to the sync case and we only need to concentrate
on one thing?
(Assignee)

Comment 3

19 years ago
Well, I was thinking we could just keep bug 6873 open, and then attach specific
problems to that.
(Reporter)

Updated

19 years ago
Blocks: 11091
(Reporter)

Comment 4

18 years ago
Now that we're able to parse the complete mailbox again, I'm not seeing any
speed difference since this bug was marked fixed.  It still takes about 3
minutes for me to load 1000 messages.
(Assignee)

Updated

18 years ago
Status: RESOLVED → REOPENED
Target Milestone: M10
(Assignee)

Comment 5

18 years ago
Then its been broken again. Reopening bug, setting milestone M10.

Updated

18 years ago
Resolution: FIXED → ---

Comment 6

18 years ago
Clearing Fixed resolution due to reopen.  lchiang...think we need and M9 Release
Note?

Updated

18 years ago
Blocks: 9161
Whiteboard: [Perf]

Comment 7

18 years ago
There is nothing to release note.

Comment 8

18 years ago
*** Bug 9316 has been marked as a duplicate of this bug. ***

Comment 9

18 years ago
*** Bug 9209 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

18 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

18 years ago
Fixed. FWIW, I don't think the case you present here ever worked.
(Assignee)

Updated

18 years ago
Status: RESOLVED → REOPENED
(Assignee)

Comment 11

18 years ago
Doh. Updated wrong bug.

Updated

18 years ago
Resolution: FIXED → ---

Comment 12

18 years ago
Oh, man, don't tease me like that!

Comment 13

18 years ago
Scott Putterman has a workaround for one of the manifestations of this bug -
don't tell RDF about incoming headers until all are received.
(Assignee)

Comment 14

18 years ago
bulldozer to M12
(Assignee)

Updated

18 years ago
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 15

18 years ago
scottip: this seems to be to a reasonable level of performance (for some
definition of reasonable). i'm going to mark as "fixed" for now: it's certainly
dogfoodable, probably even beta-able.
(Reporter)

Comment 16

18 years ago
agreed.  For loading new messages we're in pretty good shape.  Plus, David B,
has a bug open for marking messages read which can replace this bug :)

Updated

18 years ago
QA Contact: lchiang → suresh

Comment 17

18 years ago
Marking this as Verified. We are in much better shape in folder loading 
performance.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.