Closed Bug 435154 Opened 14 years ago Closed 14 years ago

"mark folder read" is very, very slow with large tables


(Thunderbird :: Mail Window Front End, defect)

Windows XP
Not set


(Not tracked)



(Reporter: ales.irsic, Unassigned)


(Keywords: perf)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080404 Firefox/
Build Identifier: version 3.0a2pre (2008052003)

I already know that Thunderbird is awfully slow with rendering messages which ocntains large tables (content of cells is irrelevant).

Strange thing is, that if I have for example 10 unread messages in folder, and I select "mark folder read", Thunderbird tops at 100% CPU for about 20-30 seconds (on Intel Core 2 Duo 3.0 GHZ !!!). Actually it takes the same amount of time, as I would manually open each message.

I think that instead of just setting some kind of flag, that all those emails are read, it actually opens them in background (and because these messages contains large tables, Thunderbirds slow rendering engine takes over).

Reproducible: Always

Steps to Reproduce:
Actual Results:  
It works OK, but it is really slowww.

Expected Results:  
Setting "read" flag in a flash.
Ales, would you be prepared to supply some example emails (save as .eml and attach to this bug) to help us reproduce this problem?
I've done a brief investigation; I don't see any reason that Thunderbird would attempt to process the body of the messages involved during the actual mark-all process.  So, a few additional questions to help isolate what case might be happening:

1) What type of mail folder is this?  IMAP/Local/etc.
2) How many messages total are in the folder?
3) Do all/many of the messages have an identical subject?

and perhaps most important:

4) Do you have one of these giant-table messages visible in the preview pane or any other message window/tab when you select "mark folder read"?
Here is ZIP of test MBOX folder with 10 large emails.
Note: may be related to bug 435172
re: Andrew

It seems that total number of messages in a folder and/or which message is displayed in right pane, does not affect the marking speed.
The only thing that affects it, is the number of unread big-table messages.

I have already reported slow rendering of those messages in bug 435172. (like Mark suggested)

It seams like these two bugs work together to be even more annoying.
Thank you for providing the zip file with the sample data.

I am unable to duplicate your problem on my OS X box (recent custom trunk build) or my Windows XP box (3a1) using the messages in the mbox Inbox file you provided.  In my testing, the individual messages display responsively (the new message is displayed before I can say "one mississippi" on an old single core Athlon64 3200+), and "Mark Folder Read" was also quite responsive.  In fact, I found doing "Mark Folder Read" on 99 cloned copies of the messages you provided still very responsive.

Do you use anti-virus software on your computer or any other utility software that might be interfering with things at a low level?  Can you verify in the windows task manager that it is Thunderbird who is dominating the CPU when the CPU hits 100% for an extended period?
Mark Folder Read doesn't care at all about the contents or size of the messages - it just seeks to a well-known offset in the mailbox, writes 4 bytes of data, and repeats for each message. A virus checker is a likely culprit.
Or an extension? Still reproducible using "thunderbird.exe -safe-mode"
Have no extensions and I disabled virus checker.

David, if your statement was true, than I would have no problems. There is something else going on.
WFM also, instant results with your zip file. I don't see that it's possible to be a thunderbird issue.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080928120750 Shredder/3.0b1pre

You might want to work through this issue in a support forum. There's a link on
Closed: 14 years ago
Keywords: perf
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.