Closed Bug 168521 Opened 22 years ago Closed 22 years ago

filter after the fact: too much disk io

Categories

(MailNews Core :: Filters, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.2beta

People

(Reporter: sspitzer, Assigned: sspitzer)

Details

Attachments

(1 file, 10 obsolete files)

20.20 KB, patch
Details | Diff | Splinter Review
filter after the fact:  too much disk io

saspitzer: runnning filter on selected folders just went crazy!
saspitzer: I heard the disk grind.
saspitzer: the UI hung, but then it came back.
saspitzer: I mean really grind!

saspitzer: I might do this:
saspitzer: LogRuleHit(hdr, PRBool flush);
saspitzer: for normal, yes, flush
saspitzer: for yours no,
saspitzer: and they give you a flush.

it's when logging is turned, working on a fix.

thanks to david for the info.
Attached patch patch (obsolete) — Splinter Review
Attached patch assertion fixes, other cleanup. (obsolete) — Splinter Review
Attachment #99081 - Attachment is obsolete: true
Attached patch update (obsolete) — Splinter Review
Attachment #99091 - Attachment is obsolete: true
Attachment #99092 - Attachment is obsolete: true
the last patch does what we want, but I found another scenario where we slam 
the disk.

file a large number of messages from one folder to the imap inbox.  then load 
the impa inbox.  we apply the filter rules to the moved headers.  (not sure if 
that is correct or not.)

so if I move a lot of msgs to inbox, we can slam the disk if we have logging 
enabled.

I'll look into this next.

but filter after the fact only flushes at the end now, and doesn't slam the 
disk.

nsMsgFilter::LogRuleHit(nsMsgFilter * const 0x04909690, nsIMsgDBHdr * 
0x01322b90, int 1) line 351
nsImapMailFolder::ApplyFilterHit(nsImapMailFolder * const 0x046d013c, 
nsIMsgFilter * 0x04909690, nsIMsgWindow * 0x03c3ed00, int * 0x0012fb54) line 
2993
nsMsgFilterList::ApplyFiltersToHdr(nsMsgFilterList * const 0x049084e0, int 1, 
nsIMsgDBHdr * 0x01322b90, nsIMsgFolder * 0x046d007c, nsIMsgDatabase * 
0x0483b778, const char * 0x04e1d028, unsigned int 282, nsIMsgFilterHitNotify * 
0x046d013c, nsIMsgWindow * 0x03c3ed00) line 285 + 29 bytes
nsImapMailFolder::NormalEndHeaderParseStream(nsIImapProtocol * 0x03aefe80) line 
2672
nsImapMailFolder::ParseMsgHdrs(nsImapMailFolder * const 0x046d0128, 
nsIImapProtocol * 0x03aefe80, nsIImapHeaderXferInfo * 0x03af0108) line 2537 + 
18 bytes
XPTC_InvokeByIndex(nsISupports * 0x046d0128, unsigned int 16, unsigned int 2, 
nsXPTCVariant * 0x079c0200) line 106
EventHandler(PLEvent * 0x078db778) line 567 + 41 bytes
PL_HandleEvent(PLEvent * 0x078db778) line 643 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01267f80) line 573 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0055027a, unsigned int 49447, unsigned int 0, 
long 19300224) line 1308 + 9 bytes
USER32! 77e11b60()
USER32! 77e11cca()
USER32! 77e183f1()
nsAppShellService::Run(nsAppShellService * const 0x012eee40) line 472
main1(int 2, char * * 0x00277ba0, nsISupports * 0x00000000) line 1508 + 32 bytes
main(int 2, char * * 0x00277ba0) line 1869 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e8d326()


Status: NEW → ASSIGNED
I think there is a filter bug here.  because when I move messages back into the 
inbox, they get moved back.

shouldn't normal (not after the fact) filters only apply to "new" headers?  
Attached patch patch for review. (obsolete) — Splinter Review
Attachment #99096 - Attachment is obsolete: true
Attached patch updated patch (obsolete) — Splinter Review
Attachment #99099 - Attachment is obsolete: true
Target Milestone: --- → mozilla1.2beta
Attached patch patch (obsolete) — Splinter Review
Attachment #99109 - Attachment is obsolete: true
Comment on attachment 99132 [details] [diff] [review]
patch, again following tips from bienvenu.

sr=bienvenu - I had a couple nits over aim, but Seth has fixed those.
Attachment #99132 - Flags: superreview+
fixed.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: