[darcs-users] GSoC Project: Improving darcs' network performance

Jason Dagit dagit at codersbase.com
Fri Apr 9 17:25:52 UTC 2010


On Fri, Apr 9, 2010 at 2:04 AM, Alexey Levan <exlevan at gmail.com> wrote:

> Hi all,
>
> I've just finished my GSoC proposal, it's at http://bit.ly/info/9CKuRh .
> I'd be glad to hear any feedback on it before deadline (19:00 UTC). (I'm
> particularly interested in negative feedback, so I could identify and
> fix the worst parts).
>

"Thus, darks works as a simple file server."  Did you mean "darcs"?


>
> Also, there are some points I'm still unsure about; I'd appreciate for
> any help on them:
>  * What happened to HTTP pipelining? Why wasn't that successful? Is
> problem in darcs, or in libs, or somewhere else? (Or nobody knows?) It
> would be worth to write about it, as it intended to solve the same
> problem as my project.
>

Darcs supports HTTP pipelining.  If you're not seeing the pipelining
happening, then I'm not sure what is wrong.  For example, the remote
webserver may not support it.  Some versions of darcs have had terrible
performance due to the amount of data received.  Meaning, sometimes the get
performance is bad after the data is received and darcs is processing it.  I
don't know what the current status is, hopefully those problems have been
fixed in 2.4, but without looking at the profiling data it's hard to
remember.

The benchmarks on the wiki are really hard to find because they seem to be
strewn across many small pages, but a few links might get you started.

Pages about benchmarks:
http://wiki.darcs.net/Development/Benchmarks
http://wiki.darcs.net/Benchmarks

And then there is a slew of individual runs on machines like this one:
http://wiki.darcs.net/Benchmarks/Quasar


>  * In description of 'darcs optimize --http' command, I'm saying that
> patches before tag don't get reordered. Actually, I'm not 100% sure
> about that. The idea I got while looking at sources is that tag is
> regular patch (to some degree) that doesn't commute with anything.
> However, I didn't find prove of it in sources, so I may be wrong. The
> technical explanation of what's really going on with tags would be
> really helpful.
>

I think for most cases this is accurate.  A tag depends on all the patches
before it so most repository interactions stop at tags.  It's possible
somethings need to look beyond tags, but I don't know the details.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100409/c699bdf0/attachment.htm>


More information about the darcs-users mailing list