David Roundy wrote:
darcs check should work to indicate the conversion went fine.
Just fired one off, I'll let you know if it finishes before I've written
this email :-)
$ darcs2 query repo
Type: darcs
Format: hashed, darcs-2-experimental
Root: /64playpen/simonmar/ghc-darcs2
Pristine: HashedPristine
Cache: thisrepo:/64playpen/simonmar/ghc-darcs2
Num Patches: 17532
A few quick performance tests. The darcs2 repository is on a local filesystem:
$ time darcs2 whatsnew -s
No changes!
2.25s real 2.04s user 0.18s system 98% darcs2 w -s
In a darcs1 GHC repository mounted over NFS:
$ time darcs whatsnew -s
No changes!
0.13s real 0.03s user 0.05s system 58% darcs w -s
The difference here is that I haven't implemented the time-stamp
synchronizing feature for hashed repositories. I wasn't sure it was
still needed (and would be nice to drop, as it's a bit hackish), since
for the darcs repository whatsnew is pretty fast. Will have to add it
to the TODO list.
2s or so for a 'darcs whatsnew' doesn't seem much, but it affects the
perceived responsiveness quite a bit. I'm used to doing lots of whatsnew
operations in emacs, and the fact that they're really snappy even on the
whole GHC tree is something I really like about darcs.
It's also possible that you're getting hurt by the cost of checking
the sha1 hashes, which we currently do in a rather paranoid way (I
like being paranoid, except when it hurts). If this is the case, we
could speed things up by using a faster sha1 hash function. Right now
we use on written in Haskell, but it wouldn't be hard to bind to a
well-optimized implementation (openssl or something).
I presume you can profile using the repository I uploaded?
But I guess I've been running on local disks long enough that I've
forgotten the cost of opening up a file over nfs... I'd best go ahead
and make this change. It's potentially a little painful, as
synchronizing the modification time of files in the pristine cache
doesn't interact well with hard linking between files in the pristine
caches of different repositories.
>
Which means either we live with a
performance cost to hard linking of pristine caches, or we store
modification times in the file contents of the pristine cache, so that
we could have multiple modification times per file. :(
So while the pristine files can be shared between repositories, the
modification times cannot, so I guess that means you need to store them
separately, perhaps in another file?
"darcs changes" seems to have a big performance regression:
$ time darcs2 changes --last=10 >/dev/null
I killed it after 3 minutes of CPU time and the process had grown to 1.4Gb.
darcs1 does this in 0.05 seconds using 2Mb. Perhaps the repository is
corrupted somehow?
Yikes! That's actually a very surprising bug. I'd be interested in
hearing if it shows up if you run a darcs2 optimize first? Either way,
of course, it's a serious bug, but that'd give a hint where the
trouble is.
darcs2 check has nearly finished... yup, the repository is consistent.
Trying optimise now...
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
