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 darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel