UPDATE: A number of posters in the comments have pointed out that it is possible to run this command on just one line in the Terminal and to leave some of it out. See the comments if you are interested in more fancy ways to get the job done.
As everyone knows, it is possible to get quite a speed boost out of Mail.app by stripping all the bloat out of its Envelope index, an SQLite database Mail uses to store senders, recipients, subjects and so on.
In a past Hawk Wings tip
, I suggested that quitting Mail, deleting the Envelope file and restarting Mail would force a rebuild that produces a leaner, faster email experience.
In October last year Dallas noticed a faster way to get the same result and posted it in the comments to that tip.
And there it remained until I noticed that Shaun Inman
(an iCelebrity and developer of Mint
which counts the peeps on Hawk Wings) had noticed it.
Here it is.
1. Quit Mail.
2. Open Terminal.
3. Type the following:
cd ~/Library/Mail
sqlite3 Envelope\ Index
An sqlite> prompt will appear.
At that prompt, type vacuum subjects;.
After a short delay, the prompt will return. Type Control-D to exit.
4. Restart Mail and enjoy the extra speed.
The first time he tried this, Rob Griffiths of macOSXHints reduced his Envelope index from 25.9MB to 4.5MB. My result was less dramatic (21.6MB -> 17.6MB) but Mail.app still felt a lot more zippy.
Some anecdotal evidence suggests that POP users don’t see the same reductions. Can any POP user out there confirm this?
UPDATE: It is easy to automate this using iCal and an applescript. See “Automating the Envelope speed trick“.
Tags: Apple Mail, Apple Mail Tips, envelope, mail.app, POP, Productivity, speed boost, sqlite
I tried the command “vacuum subjects;” at the sqlite prompt. It did speed up Mail but I suspect it also messed up the search function. Meaning I didn’t find all the mails containing a specific word when typing it in the search window.
The subject table is not the only one:
.tables shows a list of all of the tables.
sqlite> .tables
addresses messages sqlite_sequence
attachments properties subjects
mailboxes recipients threads
It might be worth to vacuum all of them.
Regards,
Hans Wolters
Hiya,
I have loads of mail delay issues on my mac but I’m using Thunderbird not mail.app.
It’s a bit of a long shot, but does anyone have any idea whether I could do something similar to speed it up..?!
Thanks :)
Off-topic reply, hoping someone might be able to enlighten me about what none of the few search hits did, including what brought me here:
I’m not exactly sure what it means (something to do with X-UID headers being out-of-sync on the server and client?) but it’s been happening intermittently ever since I started using Mail about a year ago. It stopped for awhile, then reappeared soon after switching IMAP servers a few weeks ago.
All along I’ve used fetchmail to retrieve messages from a subset of remote IMAP mailboxes, delivered to a single local INBOX and later processed with a few Mail rules to move some to their final destination mailboxes for local IMAP access. The “went negative” warning always seems to be for those remote mailboxes, which are also active in Mail accounts but not actually read, or those rules has delivered to. I read other mailboxes in those accounts which aren’t retrieved with fetchmail. Since Mail doesn’t support subscriptions it’s forced to seeing the fetchmail-retrieved mailboxes I’d rather it ignore.
That’s the basic gist of it. There are other symptoms and details but this is already long enough. Any info about why that happens and what might be done to stop it would be appreciated… thanks!
Off to read bbum’s article about vacuuming Mail’s Envelope Index to get more informed about what it actually does before deciding whether or not to do it.
Jen-
One mailbox at a time. If you highlight all of them, it greys out.
I went from 230K to 110K by deleting Envelope Index and opening up Mail.app and letting it import everything, then doing the sqlite and ended up with 110K. Granted, I have about 1000 times smaller database then the rest of you but Mail.app does feel a bit snappier, which I will always take.
28Mb -> 24Mb is not a great improvement but I use IMAP for one account and POP3 for two others – I don’t know if that made a difference…
Mail has been driving me nuts for a log time with it’s near geological performance. I have just 2 POP accounts and had a 9.5MB file size before that dropped by 50% to 4.3MB after and now that application is flying.
This should be native in the application though, one of the things I hope to see inmproved with Leopard along with Safari’s housekeeping capability.
Dave
202.3mb to 177.8mb – and a massive improvement – 10 – 15 seconds in mailbox switches has been reclaimed! It’s fantastic. Now to try the MacBook Pro with the same trick…
(For the record, about 10 IMAP mailboxes, with over 80000 messages)
I want to point out, because some earlier comments might have run afoul of this, and I don’t have time to read all the comments…
sqlite3 is a program. You run sqlite3 (which is the ’sqlite3 Envelope\ Index’ part) and then you issue sql commands to it (which is the ‘vacuum index;’ and/or ‘vacuum subjects;’ part). sql commands end in a semicolon (;).
So if you’ve run sqlite3, and you type in any of these commands, and you end up staring at a prompt (>) as if nothing’s happening, you can just enter a semicolon. Various sql implementations work this way. When they get an incomplete line (that is, one without a semicolon at the end), they assume you want to enter more of the same command. So type a semicolon. :-)
Also, Allan Jenson says this:
> >2) Menu “Mailbox†> “Rebuildâ€
> >Apply this for any maibox and folders in Mail.
> I would do this if it weren’t always greyed out.
The way around this is: You have to do it *per account.* So click the little triangle next to ‘Inbox.’ See your various accounts listed. Click on one, and then Mailbox -> Rebuild won’t be greyed out.
How can I reverse this script? Since running this script about a week ago, many people are writing saying that when they reply to emails I send them that their emails are bouncing. I’d rather have slow email and know that I’m getting everything. I definitely did speed up the application, though!
Could this be because I am running both IMAP and POP accounts in Mail?
It is only possible to modify the value of the auto-vacuum flag before any tables have been created in the database. No error message is returned if an attempt to modify the auto-vacuum flag is made after one or more tables have been created.”
possible solution: back up, recreate database, set the flag and copy data from backup. But I won’t try it, too much mail and too little time.
CONVONIX.BLOGSPOT.COM
This command is just as effective to speed up your email and runs much faster than VACUUM:
cat ~/Library/Mail/Envelope\ Index >/dev/null
Like VACUUM, the speed up effect disappears once you reboot your machine.
I tried this and unfortunately it didn’t work. Ever since I installed Google Desktop my mail has been horribly slow.
aL
I used “sqlite3 ~/Library/Mail/Envelope\ Index vacuum subjects;” and it made my envelop size smaller.
But, it seems to have destroyed the index of my Adium chat logs. Adium keeps trying to reindex them, but seems incapable of “saving” its new index, so it just starts over repeatedly. Since they’re not indexed, I can’t search my logs anymore. (No recent Adium upgrades, so I don’t think that program is to blame.)
Any ideas on what to do to restore my chat log index?
Great tip!!! This fixed my mail content search capability which, for some reason, was completely broken I could search on subject but content searching would not return results. This elixir fixed the problem!
VERY impressive for me for my IMAP email @mac.com. 9MB to 404kb. Very snappy response now.
Hans wrote:
The subject table is not the only one:
.tables shows a list of all of the tables.
[user@systemname:~/Library/Mail]sqlite> .tables
addresses messages sqlite_sequence
attachments properties subjects
mailboxes recipients threads
So the sequence is:
sqlite> vacuum addresses;
sqlite> vacuum messages;
sqlite> vacuum attachments;
sqlite> vacuum threads;
.
.
etc
Do each one to clean up each table. The performance enhancement may not be as noticeable as with just the ’subjects’ table, however, small increments add up.
The terminal session is much faster than using the built in Rebuild feature in Mail.app.
this works great i do it every month or so!
Any idea if this is still needed for leopard? Mail 3.0
Wes — Good question! The Envelope SQL database is still there, so I am guessing, yes. I’ll find out from someone who knows a lot more than I do.
Thanks a gazillion for that tip! This worked like a charm on my mail.app. I use it to check and manage half a dozen pop-mialboxes. Was slow like molasses, even worse after upgrading to MacOS 10.4.11. Envelope file reduced from 22 odd M to 18.9 but boy is it snappy now! Like new.
Thanks .. dude Any idea if this is still needed for leopard? Mail 3.0 send Me!
In Leopard Mail (freshly installed, not upgraded), this tip did indeed make a big difference to the snappiness of Mail after a vacuum.
My DB went from 158MB to 141MB after the vacuum (which took about 5 minutes to complete). So still recommended for use on Leopard…
VACUUM is SQLite’s “optimize the database” command. It theoretically takes a table name (”envelope”, as suggested above), but ignores it and rebuilds the entire database instead.
In summary, VACUUM defragments the SQLite database. This speeds up some operations, at the expense of INSERT performance (as now the file has to be extended to handle each INSERT).
No data is deleted by this command, as far as the documentation is concerned.
http://www.sqlite.org/lang_vacuum.html
POP. Big mail folder.
Used terminal, shrank from 51.1 -> 49.1mb
Windows initially refreshed quicker, but on checking mail all is back to molasses.
No so happy with Mail…
[...] any case according to some it is a good idea to clean the DB up by using the sqlite vacuum command. I’ve been playing [...]
[...] sqlite vacuum to speed up Mail.app’s index. This was written by tonym. Posted on Monday, March 17, 2008, at 3:54 pm. Filed under [...]
[...] Read the full post and many informative comments here. [...]
[...] clean up mail.app’s index and make it hugely faster 1. Quit Mail. [...]
[...] A faster way to speed up Mail.app (tags: Computer mac) [...]
[...] going on when you do this, please have a look at the blog posting over at the guys from Hawk Wings, where the inner workings and effects of the command are discussed in detail. They also have a ton [...]
Excellent tip. Our stats/findings are:
10 x POP accounts
Envelope Index: Before: 23Mb – After: 5.7Mb
Speed: Before – Slow After: Rapid
Thanks so much
Wow, not much size reduction for me (296 to 283MB) but the ’system load’ on my machine is dramatically reduced. Before, when AppleMail was very busy it would take 90% of both CPU’s or more in System time. Now it’s barely registering. Additionally, this made my disk thrash wildly (what’s with OSX not caching this? I have 4GB of RAM) for hours on end. I believe this single tip will extend my hard drive life more than anything else I’ll ever do, short of dropping AppleMail. Kudos, sir.
Zowie, wowie.
I’m not a computer internalist, yet a heavy user just the same. This was fast simple and it worked. You never get all of those at once – how great.
Thanks a lot.
With so many successful uses and therefor problems, this seems to be an endemic problem with the design of Mail.app and sqlite.
I have to run this about once a week to keep mail.app running.
I had a Fiat X-1/9 (Italian mid engine sports car) in college. Every week I had to open the hood and putz around with the rotor and coil, adjust timing, etc. I eventually got rid of that piece of junk and got a real car.
Apple needs to fix this. This Mail.app problem not a changing oil issue … this is broken down on the road side, get your took kit out, missed the meeting/interview/flight issue.
This comment is a bit late in coming… sorry for that.
My speculation as to the size reduction in POP vs. IMAP is that IMAP messages are stored on the server at all times. The computer may make a fake index to allow quicker traversals, but each message is loaded directly from the server when you click on them. POP, on the other hand, downloads all your messages initially and removes them from the server, storing them locally. This gives sqlite3 a lot more information to optimize, and a lot more information for Mail.app to handle.
I hope this helps.
[...] found this over on hawk wings and it worked like a charm; my folders in apple mail now open about 50% faster than they did prior [...]
[...] Podem ver aqui o howto original. [...]
huh–
doesn’t look like i did something right?
i followed the instructions provided;
but now my Mail.app permanently crashes — i have tried it 20 times now… each time it crashes — and asks to Ignore/Report/Relaunch.
Even after Relaunching — it offers me to Relaunch and reset settings — which doesn’t make a difference.
How could i have got this catastrophically wrong, compared to others?
Any idea — on how i can reset my mail account settings — since my mails on IMAP im less worried about my local mailbox.
[...] Mail.app seems to get slower and slower. Plus it crashes at least once a week. As I started looking around the web to find a solution I ran across this post from Tim Gaden at his blog: http://www.hawkwings.net/2007/03/01/a-faster-way-to-speed-up-mailapp/ [...]
[...] A faster way to speed up Mail.app | Hawk Wings (tags: Mac tips email mail apple osx mail.app optimization) [...]
remove the period after vacuum subjects;
[...] inbox, things were getting kinda slow. I looked to the West in search of a speed fix and found this Hawkwings.net post. [...]
[...] stumbled upon this tip for speeding up Apple Mail and it works beautifully. My Apple Mail is now very snappy with [...]
how many of you use IMAP with mail.app with success? I simply cannot get my larger accounts to connect, update, etc w/o error. I create a simple test account with a subfolder or two and that is it…then maybe it works for a day or so before the issues start to pile up!
[...] Gaden has documented an excellent tip to speed up Apple [...]
so much faster, thanks. 1 exchange, 2 imap, and public folders galore… super fast now
[...] A faster way to speed up Mail.app | Hawk Wings "As everyone knows, it is possible to get quite a speed boost out of Mail.app by stripping all the bloat out of its Envelope index, an SQLite database Mail uses to store senders, recipients, subjects and so on." (tags: Apple MacOS Mail.app productivity reference performance hack optimization sqlite3) [...]
[...] procedure and information about the vacuum statement. filed in internet/technology tagged with Apple, [...]