I do "darcs whatsnew somefile" and the performance is terrible (this is working 
on a remote filesystem that is mounted locally, so it massively exaggerates any 
problems).  Doing an strace on this simple operation produces a huge file, 
which appears to be doing lstat64 on every file in the _darcs/pristine/ and the 
working copy.

I can't think of any reason why that would be necessary, especially since I 
specifically asked for just one file.

In a bash script:

#!/bin/bash
mkdir mytempdir || exit 1
cd mytempdir
darcs init
touch file1 file2 file3 file4
darcs add file1 file2 file3 file4
darcs record -am "test"
# Expect the following to produce no output:
strace darcs whatsnew file1 2>&1 > /dev/null | egrep 'file2|file3|file4'

On Fri, Jan 12, 2007 at 04:10:58PM +0000, Luke Plant wrote:
> I do "darcs whatsnew somefile" and the performance is terrible (this is working 
> on a remote filesystem that is mounted locally, so it massively exaggerates any 
> problems).  Doing an strace on this simple operation produces a huge file, 
> which appears to be doing lstat64 on every file in the _darcs/pristine/ and the 
> working copy.
> 
> I can't think of any reason why that would be necessary, especially since I 
> specifically asked for just one file.

Just sloppy programming.  We compute the entire set of changes first, and
then select the ones affecting that file.  In our defense, there are
slightly tricky cases involving renames where simply looking at one file in
both pristine and working directory wouldn't give the right answer.  But
yeah, it's just sloppy (lazy) programming.
-- 
David Roundy
http://www.darcs.net

> I do "darcs whatsnew somefile" and the performance is terrible (this
> is working on a remote filesystem that is mounted locally, so it
> massively exaggerates any problems).  Doing an strace on this simple
> operation produces a huge file, which appears to be doing lstat64 on
> every file in the _darcs/pristine/ and the

Known issue.  The Slurpy code needs to be refined.

Note that there's no issue on a sane local filesystem, as the i-node
cache (or your OS's equivalent) will hide the problem.  However, it
will bite you badly on a remote filesystem that has synchronous
semantics for stat.

                                        Juliusz

I'll retest this was the latest darcs2 build to confirm if this still an issue.

I just sent a patch to add bugs/whatsnew.pl, which confirms that this bug still
exists. Using a hashed format presents the pristine stat calls to the un-used
files, but 'stat' is still called on extra files in the working directory.

This isn't specific to "whatsnew", is it? It seems like every command that can 
be restricted to operate on certain files slurps in the whole pristine tree 
regardless (at least, based on the progresss message), at least in a hashed 
repo. For instance: "revert", "record"...

I now pushed a fix that is limited to whatsnew's scanning the working copy to
the sprint branch. Judging by what uses the
Darcs.Repository.Internal.get_unrecorded* family of functions, we can use it for
the "changes", "mark-conflicts", "whatsnew", "revert", "unrevert", "record",
"unrecord", "remove" and "amend-record" commands too. 

I have not done anything yet about the amount of stats on the pristine.

For those following this, tux_rocker is referring to the temporary branch used
during the darcs hacking sprint of 2008-10-25

http://code.haskell.org/darcs/sprint

We'll be working on getting these patches into mainline darcs soon!

All my work on the working directory stats is now in, and the pristine access
should be taken care of by Petr's hashed-storage work.

failing-issue390_whatsnew.sh still fails; re-opening the issue.

I am upgrading this from wishlist to bug.