[darcs-users] darcs patch: refactor Slurpy to common up name compon... (and 9 more)

Jason Dagit dagit at codersbase.com
Wed Oct 29 22:53:23 UTC 2008


On Wed, Oct 29, 2008 at 1:31 PM, Ganesh Sittampalam <ganesh at earth.li> wrote:
> Hi David,
>
> OK, I've now benchmarked this work on the GHC repo in kowey's
> zoo, and the overall picture suggests significant speedups (20% or
> so) on most of the tests (get, pull, unpull, record, unrecord,
> revert), with possible slowdowns in whatsnew and get-lazy of
> about 10%.

I like that it's an overall win.  Whatsnew is a commonly used command
that people have often complained is too slow, so I don't like hearing
that is worse.  Do you have future plans for improving whatsnew?

> The slowdowns are on quite small absolute times, and I don't have an
> easy way of doing benchmarks on a quiescent machine. However overall
> the picture seems pretty positive, and therefore I'd like to submit
> these for inclusion now.

Oh, so whatsnew/get-lazy may not be representative of real use cases?
Or the slow down is ignorable assuming it will scale better now?

> To reiterate what I said before about the patches:
>
> The work is motivated by issue711, where darcs whatsnew -ls is
> slow on a large tree. A simple experiment with a directory
> with a large number of files in it showed quadratic blowups
> in the slurpy code, and in speedy_commute. Here I'm trying to
> address the slurpy code. The basic idea is to switch over
> from storing the files in a directory in a list, to using
> Data.Map.

I think someone attempted to make a version of map with better complexity:
http://hackage.haskell.org/trac/summer-of-code/ticket/1560

I wonder if it's worth trying out.

I started to look at your patches but it's a lot of stuff and all in
the Slurpy code (which I have a very weak grasp on).

Thanks!  This looks like it took a lot of time and that it pays off.

Jason


More information about the darcs-users mailing list