Open Bug 475506 Opened 16 years ago Updated 2 years ago

nsIMsgFolderListener could benefit from a msgsAdded batch notification and nsIMsgFolderNotificationService could be the batcher

Categories

(MailNews Core :: Backend, defect)

defect

Tracking

(Not tracked)

People

(Reporter: asuth, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf)

dmose noted in the gloda review process that it would be beneficial to have a batched notification for addition of messages, most specifically beneficial for the case when we open a new folder and get a ton of msgAdded notifications.

Most of the time, it's not obvious to the code generating the notifications that there is going to be a batch.  However, the nsIMsgFolderNotificationService implementation could deal with this using a token-bucket-style approach.  Once it generates some number of single notifications per a time period, it would fall back to accumulating them and releasing them when its batch threshold is reached (ex: 500) or a timer expires.

As sid0 points out, in the cases where code actually wants to act on every individual message, this won't immediately help the XPConnect-crossing case alone, as queryElementAt will still cross.  However, we can probably fast-path that with a helper function, which users of fixIterator could get for free.  But for code that only needs to know that one or more messages was added, this could be useful.  For example, gloda falls back to "sweep indexing" once its limited event-driven queue is overloaded.  With this notification, gloda could immediately fall back to sweep indexing with little cost.
Keywords: perf
Blocks: 1023000
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.