A Pointed Critique of Thunderbird 3's Performance Compared to v.2 234
PerfProtector writes "Did you recently install Thunderbird 3 or upgrade from Thunderbird 2 to Thunderbird 3? Did you notice any severe slowdown in your machine or a major decrease in its performance? Well, many people around the world encountered these problems. We wrote a technical analysis about the severe problems that are caused by Mozilla Thunderbird e-mail client. These problems include anomalous usage of CPU, memory, hard disk and Internet bandwidth. You can read the full analysis, including several graphs that show how bad the situation is and what went wrong from Thunderbird 2 to Thunderbird 3. For example, while CPU utilization of Thunderbird 2 is usually between 0% to 10%, with an average of 0.3%, Thunderbird 3 CPU utilization is between 5% to 80%, with an average of 30% — 100 times more than Thunderbird 2. In addition, during long periods of time, Thunderbird 3 used more than 50% of the overall CPU resources.This behavior slows dramatically the whole machine." It's worth noting that this analysis comes from developers who have developed a (freeware) tool they claim will improve Thunderbird's performance, but they explain also how to do so with manual changes.
Did I notice a severe slowdown? (Score:5, Interesting)
Nope.
Did I notice any slowdown at all?
Nope....
Solutions for problems that (to me) don't exist...
Who still uses a local email client? (Score:2, Interesting)
Seriously, they require your computer to go everywhere you do. Web email is the way to go.
Plus all the thunderbird users are annoying because they send messages every coupe years about their email changing because they changed ISPs.
One web-based email account fan fix all that.
If your internet is out -either at the provider or your house, then what good is email anyway?
Re:Did I notice a severe slowdown? (Score:3, Interesting)
Me neither. The only thing that bothers me is that it doesn't write new mail in the tabs.
Re:New features consume resources, news at 7 (Score:3, Interesting)
Their claim as to how long it took to do the full text indexing of the mail seems dubious to me. I've got a similar amount of mail, and the time it took to index was more like minutes, not days.
Must be a YMMV thing. After four days of waiting for 30 seconds or more at a time just to do simple things [and even longer just to exit the program; the OS kept inviting me to kill the program since it didn't actually close sufficiently quickly -- every time I exited; that got real old real quickly], I turned off all the indexing. I kept hoping that it would finally finish indexing, but there was no indication here that it was ever going to do so. It seemed (here... again, YMMV) that simply receiving a new e-mail into a folder would cause the entire folder to be reindexed. When one has more than ten thousand e-mails in a folder, that brings even a powerful machine to its knees.
Re:Duh? (Score:4, Interesting)
The two proposed changes in the article are to :
- disable the global indexer
- disable caching of messages to the local computer
I consider it a design flaw that these two settings are on by default, also for IMAP folders. The whole point of IMAP folders is to keep your email on the server. I don't want to download 4+ years worth of e-mail to my computer. I had the same problems and immediately switch these two options off on any new installations.
I found this already on May 5th [friesoft.nl]. Didn't know about the options though. I ditched version 3 for 2 for a short perios of time afterwards.
Re:New features consume resources, news at 7 (Score:3, Interesting)
IMAP4 has a "SEARCH" capability in the base standard (section 6.4.4 of RFC 3501). If an IMAP client detects the server has this capability, why not just let the server handle it by default?
For the sake of my laziness and for everyone else reading along, is there an official recommended setting in Thunderbird to tell to use only server-side searching on a particular account and not to bother indexing it?
Re:Did I notice a severe slowdown? (Score:5, Interesting)
Well your lucky then. I upgraded to thunderbird 3 half a year ago and had to downgrade back to thunderbird 2. The reasons were exactly the same as the article, all around poor performance, many crashes and problems. I tried some fixes such as disabling indexing, but they only made it bearable. Thunderbird 2 however is rock solid on my quad core machine.
Do you use both imap and pop? Are you on linux instead of windows? There is probably some way you are using the program that does not reflect the majority. I have heard many reports of people with problems with thunderbird 3 performance. Simply take a look at their forums to get a good sampling.
Mork (Score:5, Interesting)
The problem is Mork. It's a stupid old database that Mozilla products are saddled with. When you have a big one, the whole damn thing needs to be loaded into memory to be parsed. Big folder? Bam, there goes a hundred megs of RAM. Swap if needed.
Replacing Mork with sqlite started a long time ago, has achieved limited success in some Mozilla products, and has been effectively abandoned in Thunderbird.
All this burns tremendously more computing resources than are really needed. Why does Mozilla hate the environment?
Re:Indexing (Score:2, Interesting)
Upgrade forced me to abandon Thunderbird (Score:5, Interesting)
At work, I have a Windows machine I need to use. I installed Thunderbird on it to read my personal email.
One day, Thunderbird offered me an update to Thunderbird 3. Sure, why not; I let it upgrade.
So, the next day I got an urgent email from the corporate IT department demanding to know why the corporate antivirus was reporting dozens of viruses on my work computer! I was not pleased.
My email server has a virus scanner (ClamAV of course), and when it detects a virus, it shunts the virus email message into a special folder. I rarely look at the folder or worry about it. Well, Thunderbird 3 changed the default behavior without asking me anything, and downloaded every message in every folder I have. Not just headers, message bodies as well. Thus, it downloaded a bunch of virus emails onto the hard disk of my corporate Windows desktop computer.
Long story short, IT ordered me to uninstall Thunderbird to make sure that this could never happen again. (IT recognizes that the viruses were never active on my system, but they officially have a zero-tolerance policy about viruses being present inside the corporate network at all.)
So I am no longer a Thunderbird user. I found another way to read my personal email while at work.
I was always happy with the old policy, of downloading message headers only, and grabbing the message bodies when I actually opened an email to read it. The new policy might make sense if I had a single machine that I always used to read email and I always wanted my email stuff to be as fast as possible (everything cached to the local hard disk). But I use IMAP and I read my mail from a half-dozen different computers, and the vast majority of my email on my server is old stuff I rarely look at. The new policy of downloading everything makes no sense for me, and I didn't see any way to globally change the setting; it looked to me like you need to change the setting on a folder-by-folder basis. (I could be wrong about that, but it doesn't matter because I had to abandon Thunderbird anyway.)
I don't think defaulting to downloading the entirety of every message on a server is a good idea. And it led to me being forced to abandon Thunderbird, so Thunderbird has at least one fewer user as a result.
steveha
Re:Mork (Score:5, Interesting)
Classic mistake - writing your own database. This was a long-standing vice in the UNIX world, BIND and Sendmail being the classic offenders. for a long time, Windows had an edge - Jet, which is a little database engine used by applications. The open software world now has sqlite, although it's not used well in Firefox.
At one point I was trying to explain that a problem they had with duplicate entries in the password database should be fixed by making one field a unique key. "But that would break programs", was the objection. It would break the ones that were inserting bogus data, yes. The solution implemented was a JavaScript kludge that tried to fix the database when Firefox exited, which was O(N^2) at least and could hang Firefox on exiting. So the solution to that was to tell users to get rid of unneeded password entries. Some developers just have no clue about how to use databases.
SQLite isn't a bad database, provided you don't need to do many concurrent updates. (It can handle concurrent updates correctly, but the locking works by polling and retrying a file lock, which is painfully slow. So don't use it to run your web site. Get MySQL or Postgres,) Given what Firefox does, it really should keep its messages in SQLite databases, not "folders".