Patch #44599
open
Document in doc/RUNNING_TESTS how to speed up Mercurial tests by using chg
Description
The attached patch adds a section to doc/RUNNING_TESTS that describes how to make the Mercurial tests much faster by using chg.
Unlike the commands of other SCMs such as Git and Subversion, the hg command is slow to start because it has to start the Python interpreter every time it is invoked. On my macOS machine, git --version takes about 0.01 seconds and svn --version about 0.06 seconds, while hg --version takes about 0.2 seconds. Since the Mercurial tests invoke hg 470 times, most of their run time is spent on starting the command.
chg is a client for the Mercurial command server and avoids this startup cost. To use it, set scm_mercurial_command in config/configuration.yml:
test: scm_mercurial_command: chg
I measured the run time of the following three Mercurial test files (98 tests in total) with hg and with chg:
test/unit/lib/redmine/scm/adapters/mercurial_adapter_test.rbtest/unit/repository_mercurial_test.rbtest/functional/repositories_mercurial_controller_test.rb
All tests passed in both cases.
| Environment | hg | chg |
|---|---|---|
| macOS, Mercurial 7.1 | 177 seconds | 27 seconds |
| GitHub Actions (Ubuntu 24.04, Mercurial 6.7.2) | 102 seconds | 29 seconds |
The patch changes only the documentation.
Files
Updated by Holger Just 20 days ago
I actually have not much of an idea about Mercurial, but if chg is generally faster wouldn't it make sense to try to detect and use it by default (in preference to the hg command)? That way, Mercurial repo access could be faster for production use too.
Would there be any downsides to that?
Updated by Go MAEDA 20 days ago
- Target version changed from 6.1.6 to Candidate for next minor release
Thank you for the suggestion. I think it is a good idea. If chg is installed, operations that run Mercurial would become faster without any configuration.
One downside is that the chg server process stays running and increases memory usage. However, the server exits automatically 3600 seconds after it was last used, so the memory is not occupied permanently.
I will look into an implementation that uses chg by default and falls back to hg when chg is not available.