From Simon Marlow on
http://lists.osuosl.org/pipermail/darcs-users/2009-August/021058.html
:

$ darcs show repo
           Type: darcs
         Format: hashed
           Root: d:/builds/ghc-testing
       Pristine: HashedPristine
          Cache: thisrepo:d:/builds/ghc-testing, cache:C:\Documents and 
Settings\simonmar\Application Data\darcs\cache
boringfile Pref: .darcs-boring
Default Remote: x:/ghc-HEAD
    Num Patches: 21106
$ time darcs w -s
No changes!

real    0m3.126s
user    0m0.000s
sys     0m0.015s
$ darcs --version
2.3.0 (release)

Compared to Linux, where the time is ~0.25s.  These are all local 
filesystems.

-----------

So we've eliminated issue973 and we're using local drives only and we have
Petr's issue1202 patches.  So what's a reasonable way to attack this?

Why are we fast on Linux and slow on Windows?

I guess we can start with profiling.

Simon: what happens when you run whatsnew a second time?  Could it be some need
to build the index first and then use it later?

Something has happened since my previous report.  On the very same repository,
but with a freshly compiled darcs 2.3.1:

$ time darcs w -s
No changes!

real    0m13.312s
user    0m0.000s
sys     0m0.031s
$ time darcs w -s
No changes!

real    0m1.328s
user    0m0.000s
sys     0m0.000s
$ time darcs w -s
No changes!

real    0m0.813s
user    0m0.000s
sys     0m0.031s
$ time darcs w -s
No changes!

real    0m0.859s
user    0m0.015s
sys     0m0.000s


Less than one second is entirely reasonable, even if it is still a factor of 3
or so slower than Linux.  Might as well close this ticket, I think.

I'll mark this presumed-dead (for lack of understanding on our part what
changed), but if Petr you had some sort of explanation for why the
hashed-storage in 2.3.1 (or whatever) changes things, I'd be happier...

I guess that the difference is the version of hashed-storage "forced"
by cabal. 2.3.1 forces the most recent one, that may have
optimizations.

Salvatore