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
_______________________________________________
darcs-devel mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-devel
