Categories
Mercurial

Mercurial is getting slower

I swear Mercurial is getting slower.  I regularly wait 10 seconds or more for basic operations like ‘hg diff’, ‘hg revert –all’, ‘hg qref’ (and don’t ask about ‘hg up’).  I haven’t done any real measurements but I’m sure it didn’t used to be like that.

I wonder if it’s because (a) we have more revisions in the tree (more than twice as many as when I started working for Mozilla two years ago), or (b) we have more code in the repository, or (c) something else.  I’m pretty sure it’s not (d) something wrong with my machine, because I’ve done disk tests that indicate it’s working fine.

7 replies on “Mercurial is getting slower”

db48x: Thanks for the tip. I do most of my development on Linux. But I don’t run ‘hg status’ very often, and AFAICT that’s the only command the inotify extension speeds up.

What version of hg are you running? Maybe you can join #hg on irc.m.o and we can figure out what the cause might be. I know that hg 1.8 contains some fixes that might help large repositories.

You did try/compare to fresh clone, right? Fragmented a lot history file in wd/.hg/ could possibly horribly affect performance.

stef: I work with several clones, and usually they are anything but fresh. I’ll try recloning and see if that helps. Thanks!

Contrary to e.g. git, Mercurial saves a single file in the hidden .hg directory per every file that ever appeared in the repo (AFAIK), and that hidden file keeps the history for the real file.
Because of that, if you’re not using a COW filesystem such as btrfs, you easily end up with heavily fragmented files, and every hg diff, etc that doesn’t work on specific files needs to read those files in addition to your working set to find out what actually changed. I can imagine that this can cause slowdowns.
I certainly see a big difference in perf between comm-central (faster) and mozilla-central (slower because way larger) on the initial hg qpop -a I do daily, but once the whole repos have been access for this once, other operations go reasonably fast on both after this as long as caches are hot.

Comments are closed.