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:
zo...@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
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
