- General performance questions
- darcs get issues
- darcs pull issues
- darcs record issues
Answer from 2012-08-02
Darcs 2 (introduced in 2008-04) reduces the name of scenarios that will trigger an exponential merge. Repositories created with Darcs 2 should have fewer exponential merges in practice. For older repositories, see Should I convert my repository to the Darcs 2 format?.
We hope to introduce a
darcs rebase command in Darcs 2.10 that helps you to avoid situations that trigger an exponential merge.
Fixing the underlying patch theory problems will potentially take us a very long time, but we are working on it.
Use the lazy get feature
For one-off or throwaway branches, you should consider using the darcs get –lazy feature to fetch repositories. This will only fetch the patches which are strictly necessary for darcs to copy the repository, and fetch any future patches only on demand.
Use a local hard disk
Your darcs global cache should live on a local drive. If your home directory is on NFS (for example), it may be a good idea to do something like
mv ~/.darcs /my/local/disk/ ln -s /my/local/disk/.darcs .
Tag your repository
The first issue is that darcs may be attempting to retrieve all patches in the remote repository from the last tag. Here are some things to try.
- Look in the
_darcs/hashed_inventoryfile of the remote repository. How many patches are there in that inventory? These are all patches that darcs is liable to retrieve, even if you already have them.
- What happens when you create a tag in the remote repository or push it over? By rights, the size of the inventory should drop to zero (starting from the tag you just pushed). If not, upgrade to a later version of Darcs. In the meantime,
darcs optimize --reordershould fix it, emptying out your inventory.
Check for network problems
- See if the same darcs operation is significantly faster when dealing with a repository that is on the same machine.
- If you are using ssh, check how long it takes to make a single SSH connection. If you are using a darcs 2 client on both ends, you automatically get SSH connection sharing, so this should not be an issue.
Check for conflicts
Finally, do you have any conflicts or merging to do? If so, you may be dealing with the infamous exponential time conflicts bug (for example, if you a series of nested conflicts, or you have two large and identical darcs patches to merge). See the Conflicts FAQ for a possible workaround to this. But note that this should only affect you if you are actually merging patches. If you are just pushing to or pulling from the trunk without any merging, you are not dealing with a conflicts issue.
Talk to the Darcs Team!
We’re interested in improving Darcs performance. We think that we’ve been making some good progress, and we want to hear back from you if you are experiencing any slowness so that we can have a better idea what to fix.
Please contact us at firstname.lastname@example.org
Upgrade from darcs 1
If you upgrade both your client and your server to a version of darcs 2, darcs will be able to use the darcs transfer-mode ssh connection sharing feature to reduce the number of ssh-connections to at most 2 (this has an added bonus of not making you type your password a lot!). Moreover, since darcs 2.2, a global cache is created in ~/.darcs/cache, making get and pull commands faster.
If you can’t convince the remote end to make Darcs 2 available, you can set up connection sharing on the SSH level by adding this to you ~/.ssh/config:
Host * ControlMaster auto ControlPath ~/.ssh/master-%r@%h:%p
Also, large or complex conflicts can cause darcs 1 to use an exponential amount of CPU power to solve the problem, giving the appearance that darcs is “spinning” or “hanging”. Darcs 2 mostly avoids the problem in practice, but you should use the new darcs 2 format repositories instead. See Conflicts FAQ for details.
There are three directions in which a VC system can scale: having long histories, having a large source tree, and having large single commits.
Darcs scales well in the first direction, if you know what you’re doing. In other words, Darcs should have no problem dealing with 10 years of history and tens of thousands of commits, although it might require some manual intervention every few months (darcs optimize). Making sure to tag regularly also helps with this sort of scaling.
In the other two directions, darcs now scales moderately well, due to recent improvements. Darcs should be able to handle a repository the size of the linux kernel, and should be able to handle patches that make changes of the size of the linux kernel. Some commands may yet not be optimized to scale as they ought, and some are inherently slow (annotate, for example) due to the format in which darcs stores information. Reports of commands that behave poorly on large repositories are welcome.
Here are some data points about people’s experiences using darcs on larger projects. Note the date that these were published – darcs has been improving in scalability with each release:
darcs optimize. See also the Growing Pristine Problem to understand the cause of this growth.
On repositories with darcs 1 semantics (when
darcs show repo shows
darcs-1 in the
Format: line`), darcs has been known to ‘spin’ and take a tremendously long time to complete certain tasks. Although rare, it’s useful to know how to recover from such a situation.
If you can’t wait for darcs to finish, you should be able to safely use
Control-C to cancel the operation and try another approach. Unless you are doing one of the
un- commands at the time, you shouldn’t be able to mess up your repo. You may need to clean up a lock file named
_darcs/_lock (documented elsewhere on the wiki), and run
darcs check and
darcs repair to check and repair any inconsistencies that may have developed.
This may be related to the infamous exponential merge problem. Have a look at the conflicts FAQ for more help
Do you have a single very large patch? As of now, darcs does not cope very well with large patches (see issue80). The typical case that bites people is trying to recursively import your entire repository with
darcs add -r .. As a workaround, try recording in smaller chunks.
What is the size of your pending patch?
ls -lh _darcs/patches/pending
If it is very large (say, over 2MiB), it may be worthwhile to try again with a clean pending
mv _darcs/patches/pending _darcs/patches/pending.bak
N.B. this will make darcs become unaware of any add/remove/replace actions that have been performed (any changes to the working directory will still be present though).
Darcs’s poor handling of the “pending patch” is one performance area that we need to work on improving.