User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131205075310 Steps to reproduce: To reproduce this problem, you need to have an excessive ammount of incoming emails in your inbox (hundreds), lets say 500-1000 at least (since the last time you ran the client). The secondary presumption is to have many filters (20+). When you launch the client, it begins to apply every filter per every message (which mean something like 10000-20000 of applications). Actual results: The problem is that the client tries to synchronize and index hundreds of messages while applying thousands of operations at once. This concurrency results in very poor performance of Thundebird client. Most of the time you cannot even close the client properly while this operation takes place (closing the windows does not end the process in most cases). Using the menu to close the client works sometimes. Workaround: Kill the process, launch the client, apply the filters manually on inbox folder. Expected results: Now the tricky part. While applying the filters on the inbox folder manually, you can notice that it finishes pretty quickly. The feedback from corporate environment is that while the client automatically apply the filters on start per message very "slowly" (operation can take tens of minutes depending on your filters), applying it manually on the folder resolves the problem in tens of seconds at maximum. The conclusion is that when starting the client it should behave in one of these options: a) Apply the filters on the inbox folder as a whole (one filter = one operation) rather than per message (one filter x one message = one operation). b) Temporary turn of synchronization (of email bodies if enabled) and indexing, apply the filters and after headers have been downloaded and messages filtered, only then start the synchronization od email bodies and indexing.
This may be because each incoming message is written to the mbox file and the file is synced to disk. This is to avoid loss of messages in case of crash or if the app is killed. You may try setting the filters to run "after classification". It is an option in the filter editor. Check if that does not produce better performance: first messages are downloaded and written, then filters run.
Thank you for the feedback. I will try to reproduce under new settings. Unfortunately I will be able to bring feedback circa in a week.
Hello, So far I have not been able to fully confirm better responsiveness, however what I can confirm is that the rules now applied on one computer worked in the expected way (one filter applied on the whole inbox instead of every inbox message). I will try to gather more feedback.
Ok, I can confirm that the responsiveness is better for sure. Other possible improvement lies outside of scope of Thunderbird. I believe so we can close this one.
So the setting of running filters "after classification" did help you?
Correct, it seems to me that if an email is filtered after spam classification, then all such emails are filtered at once. All filters that are applied before classification are applied kind of "per email" or "less efficiently" would I say.