[darcs-devel] announcing darcs 2.0.0pre1, the first prerelease for darcs 2

Simon Marlow simonmarhaskell at gmail.com
Thu Dec 13 09:35:52 UTC 2007

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...


More information about the darcs-devel mailing list