Mail search y u slow

Dear Lazyweb, some time in the last few months, searching in Mail.app has gotten ridiculously slow. Type something into the search field, wait 25+ seconds for the list to update. It used to be instantaneous. Any ideas for un-fucking it?

I assure you that if you decide to "just google that for me", all you're gonna find are decade-old posts saying "reset your BIOS NVRAM while slowly turning thrice widdershins".

Already tried: "sudo mdutil -E /" and "mdimport -r /System/Library/Spotlight/Mail.mdimporter"

Tags: , , , ,

12 Responses:

  1. Dan Hon says:
    2

    This problem comes up for me now and then. Sometimes rebuilding the mailbox works, sometimes not. Sometimes completely deleting the account and adding it again works. Both are infuriating.

    • jwz says:
      1

      As far as I am aware, all that "rebuilding the mailbox" does is delete the mbox index and rename literally every file. The mbox index is used for file retrieval, not for search.

      Deleting the account might make sense if desktop Mail.app made use of server-side search, which it does not and has never done, so no.

  2. dd says:
    9

    Vacuuming the index usually works for me… as with some these days, mileage may vary.

    sqlite3 ~/Library/Mail/V9/MailData/Envelope Index vacuum;
    • jwz says:
      5

      This seems to have helped!

      And I don't understand why, since the Envelope Index should be about file retrieval, not search, so that should be bounded by the number of search hits in the Spotlight index. I was seeing 25 seconds on a search with only 950 results.

      • Chad says:
        2

        I used to do this semi-regularly, roughly once or twice a year when Mail.app would get slow. The second time I scripted it. The 5th or 6th time I adapted the script to hunt down the file after OS updates moved it - after a while, it became clear that the “9” in the V9 path segment above was a version number of some sort.
        My MacBook Pro died before I got up to V9, but if you decide to script it, I recommend some osascript “kill Mail, pop up warning that Mail should really be dead” intro and an ls -l glob confirmation step in the script.
        To be honest, I never actually saw it corrupt the envelope index by vacuuming it while Mail was running, so maybe that’s cargo-cult vestiges, but it made sense at the time.
        Hope that helps.

        • YanM says:
          1

          SQLite does do concurrency... so it shouldn't cause a problem with data integrity, but it might confuse Mail, so your caution is reasonable.

          • Don says:
            1

            There's documentation for how the command works on the sqlite site. It ought to be pretty safe, with the worst result being that trying to run vacuum will fail if it can't get a write lock. I guess Mail could be caching a rowid into a table without a primary key but that's enough levels of bad choices it seems at least a little unlikely.

            That said, I still just exited and restarted Mail after running the command myself because the cost of the prevention is very small compared to the cost of it fucking up my mail.

    • Nate says:

      Thank you! Same problem and this helped me.

  3. tfb says:

    The last time something like this happened to me, after a lot of mdutil chicken waving I did

    rm -rf '~/Library/Mail/V8/MailData/Envelope Index'*

    which probably now needs to be V9 or whatever, with mail stopped, and things got better.  This seems compatible with another comment.

  4. asan102 says:
    2

    Your mail.app search actually reliably returns results? I would find content in what you've got rather than risk angering it.

  5. B says:
    2

    The same exact thing happened to me: it went from "works reasonably well" to "shit the bed slow" almost overnight, sometime in the past 6 months. And I could not fix it. About a week ago I migrated to a new M2 laptop. I am not exaggerating, the performance went from "10 minutes to return filtered results" to "filter basically in real-time."

    Even if we generously assume the M2 machine is 10x more powerful (probably more like 3-4x, 2019 -> 2023), the actual performance I see is 10,000x faster. I am going to go try the re-build commands on my old machine right now.

  6. Don says:

    I've seen this as well; I'll try the above suggested sqlite command. It would be only half as infuriating if the stupid program actually provided any sort of indication that something's even happening. I key in a search term and hit return and... nothing. No beachball, no change in appearance in the search term, even the "Searching" text above the found messages doesn't draw until after its done its laboriously slow search. Apple isn't /great/ about this - see the wee tiny searching indicator you get from Finder in the bottom right corner of the window - but usually there's something.

Leave a Reply

Your email address will not be published. But if you provide a fake email address, I will likely assume that you are a troll, and not publish your comment.

Starting a new top-level thread.