When doing an operation on an untracked file, the performance is slow. For example, in my linux kernel tree: : abulafia:pts/9; hg --time log foo Time: real 19.270 secs (user 18.490+0.000 sys 0.440+0.000) This causes poor performance in mercurial.el when adding new files, because it does an hg log -l1 newfile.
The cause is this code snipped in cmdutil.py: if node is None: # A zero count may be a directory or deleted file, so # try to find matching entries on the slow path. slowpath = True break And actually it's wrong, since it could be a directory even when there's a filelog. A possible fix might be to check the pattern against the store (I don't think we have the API for that).
Another issue if that --limit 1, doesn't break at the first match in the slow path...
Fixing this will also take care of issue1302
We might add some smarts to our new store logic to ask 'is this file/directory in the history?' quickly.
I think it would be very useful, and it could help for other things.
I have the beginnings of a patch: http://hg.xavamedia.nl/mercurial/djc.mq/file/434408c53ce8/store-contains mpm has commented he wants directory support in there, and it doesn't support fncache repos yet because it predates them.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 08:54 EDT --- This bug was previously known as _bug_ 1340 at http://mercurial.selenic.com/bts/issue1340
The localrepo.file method is now present to do the right thing for files. There's no corresponding API for directories yet, but that shouldn't be hard to add.
Fixed by http://selenic.com/repo/hg/rev/6d218e47cf9b smuralid log: speed up hg log for untracked files (issue1340) 'hg log' on untracked files tends to be fairly slow. The root cause is that we end up using the 'slowpath' when we can't find a revlog for the files listed. This could happen if the file in question is an untracked file, or it is a directory. This diff tries to speed up 'hg log' (by avoiding the slowpath) for files if we can determine if that file is not (and was never) a directory. We use the previously added store.__contains__ methods to test if the directory exists (or existed) in the store. To avoid changing any existing semantics, this 'optimization' kicks in only when none of the files listed as arguments to the hg log command exist in the store. (please test the fix)