It's in main, so this is resolved. 1.0.2 was released from the stable branch,
which doesn't have this. I think the next release will be from main/crew.

Seems this didn't make it into Hg 1.0.2. Unfortunate.

Thanks! Back to the vicinity of 0.9.5's speed.

Fixed in 9eb274d773d9

I'll look into it when I have a minute.

bisect says:

changeset:   6275:fda369b5779c
user:        Matt Mackall <mpm@selenic.com>
date:        Sat Mar 15 10:02:31 2008 -0500
summary:     diff: use copy smarts from copies.py

It would certainly be nice to have tests for this.

For now, though, it would be more interesting to bisect to see what caused the
regression.

If you have a large project checked out, and type

$ hg diff some/particular/file

where the named file is modified, Hg 1.0 will take much longer than Hg 0.9.5.
strace (on Ubuntu) shows 1.0 (and crew dev versions) stat'ing the entire working
directory, even though there is no way such information could be relevant.

For a big project, this regression can make basic operations orders of magnitude
slower, especially with cold disk caches.

Surely there is some way to augment unit tests for basic commands to ensure that
they do not inspect irrelevant parts of the working copy?

Demo:

$ hg init
$ for i in 0 1 2 3 4 5 6 7 8 9; do for j in 0 1 2 3 4 5 6 7 8 9; do for k in 0 1
2 3 4 5 6 7 8 9; do mkdir -p $i/$j; echo stuff > $i/$j/$k; done; done; done
$ hg -q ci -A -m new
$ echo more >> 5/6/7
$ strace hg di 5/6/7 2>&1 | fgrep `pwd`