TortoiseHg is Slow

Ok, answering my own question because I found the answer while following Tim's advice.

The culprit is kbfiles from FogCreek. Disabling that dropped stat times from 12 seconds to .7 seconds. Likewise, the GUI opens faster than I can time. Re-enabling it causes everything to slow down drastically again.

It doesn't look like every slow thing can be blamed on kbfiles, but the worst of it can. (Specifically, shelve is still pretty slow -- CPU bound. We can work around that, though.)

That is a ton of files... and some are awfully big. How does it perform without the larger files? Binary files aren't exactly the best thing to track with hg/git, in my humble opinion.

What about breaking the big repo up into smaller ones. Do they really need to be in 2 HUGE repos?

Maybe a defrag on the hard drives could slightly improve some of those times. Also look at the extensions that have been created to help deal specifically with big binary files. See here:

https://www.mercurial-scm.org/wiki/HandlingLargeFiles

In some cases the advice given in the documentation may be useful for improving THG speed:

5.4.8. Performance Implications

There are some Workbench features that could have performance implications in large repositories.

View ‣ Choose Log columns…

• Enabling the Changes column can be expensive to calculate on repositories with large working copies, causing both refreshes and scrolling to be slow.

View ‣ Load all

• Normally, when the user scrolls through the history, chunks of changesets are read as you scroll. This menu choice allows you to have the Workbench read all the changesets from the repository, probably allowing smoother moving through the history.

In my own experience these are definitely worth doing! You should at least try them and see if there is a noticeable effect.

---

Also, if you have read Why is mercurial's hg rebase so slow? there is a setting which can speed up rebase significantly:

By default, rebase writes to the working copy, but you can configure it to run in-memory for better performance, and to allow it to run if the working copy is dirty. Just add following lines in your .hgrc file:

[rebase]

experimental.inmemory = True