[darcs-users] GSoC: network optimisation vs cache vs library?

Zooko Wilcox-O'Hearn zookog at gmail.com
Wed Apr 14 23:23:46 UTC 2010


For what it is worth, the members of the Tahoe-LAFS project are still  
pretty dissatisfied with darcs's performance.

Our project web site was just down for about an hour and a half a  
couple of hours ago. The reason turned out to be that there were  
about a dozen darcs processes running trying to answer queries like  
this:

darcs query contents --quiet --match "hash  
20080103234853-92b7f-966e01e6a40dbe94209229f459988e9dea37013a.gz"  
"docs/running.html"

This is the query that the trac-darcs plugin issues when you hit this  
web page:

http://tahoe-lafs.org/trac/tahoe-lafs/changeset/1782/docs/running.html

That particular query when run in isolation (i.e. not concurrently  
with dozens of other queries) takes at least 20 seconds, and about 59  
MB of RAM.

Enough of these outstanding queries had piled up that the server ran  
out of RAM and stopped serving our trac instance or allowing ssh  
access for about an hour and a half.

Another common complaint among new Tahoe-LAFS developers is that the  
following command takes a very long time:

zooko at localhost:~$ time darcs get --lazy http://tahoe-lafs.org/source/ 
tahoe-lafs/trunk
Finished getting.

real    5m25.642s
user    0m1.950s
sys     0m0.373s

Note that we are still using darcs-2.3.0 because that is what is in  
Ubuntu Lucid (Long-Term Support) and because what I read about  
darcs-2.4 seemed to indicate that it wasn't actually a performance  
improvement for the tasks that I cared about and might actually be a  
performance regression.

Regards,

Zooko


More information about the darcs-users mailing list