3

On big repository, hg status can be very slow and that can be a problem if we want to display the status of the repository in the shell prompt.

Here is the result of hg --profile status:

   CallCount    Recursive     Total(s)    Inline(s) module:lineno(function)
        7682            0      0.3287      0.3287   <mercurial.osutil.listdir>
       63067            0      0.2052      0.2052   <method 'match' of '_sre.SRE_Pattern' objects>
           1            0      0.7164      0.0735   mercurial.dirstate:999(traverse)
           2            0      0.8105      0.0496   mercurial.dirstate:1102(status)
         139            0      0.0420      0.0420   <zlib.decompress>
       62501            0      0.1137      0.0339   mercurial.dirstate:617(_normalizefile)
          12            0      0.0307      0.0307   <method 'read' of 'file' objects>
       63760            0      0.0283      0.0283   <method 'get' of 'dict' objects>
           1            0      0.0217      0.0217   <mercurial.parsers.make_file_foldmap>
         376            0      0.0508      0.0202   mercurial.manifest:468(walk)
       70079            0      0.0327      0.0170   mercurial.posix:241(normcase)
           1            0      0.0167      0.0167   mercurial.dirstate:200(_dirs)
       70079            0      0.0156      0.0156   <mercurial.parsers.asciilower>
           2            0      0.0137      0.0137   <mercurial.parsers.parse_dirstate>
       62875            0      0.2166      0.0116   mercurial.match:177(__call__)
           4            0      0.0113      0.0113   <method 'update' of '_hashlib.HASH' objects>
           1            0      0.0107      0.0106   mercurial.manifest:451(_dirs)
         105           75      0.0132      0.0081   <__import__>
           2            0      0.7559      0.0069   mercurial.dirstate:940(walk)
           2            0      0.0062      0.0062   <mercurial.mpatch.patches>
         724          678      0.0188      0.0061   sre_parse:395(_parse)
        1198         1152      0.0094      0.0056   sre_compile:64(_compile)
        3866            0      0.0043      0.0040   re:208(escape)
        6227            0      0.0044      0.0036   sre_parse:193(__next)
           1            0      0.0767      0.0028   mercurial.manifest:1307(read)
        1431         1152      0.0032      0.0026   sre_parse:151(getwidth)
           1            0      0.0219      0.0026   mercurial.dirstate:167(_dirfoldmap)
       30130            0      0.0024      0.0024   <method 'append' of 'list' objects>
           1            0      0.0022      0.0022   mercurial.manifest:407(__init__)
        7573            0      0.0036      0.0022   sre_parse:141(__getitem__)

I already found an optimization for hg branch (see here for more details), but I can't find on for hg status.

Do you know some magic trick to improve that. I don't need to know the details of which files are dirty or not, I simply need to know if the repo is clean or not so I can display a clean or red prompt.

Thanks!

Creak
  • 4,021
  • 3
  • 20
  • 25

1 Answers1

1

Have you tried the FsMonitor Extension?

Description from the wiki page:

Integrates the file-monitoring program Watchman with Mercurial to produce faster status results.

On a particular Linux system, for a real-world repository with over 400,000 files hosted on ext4, vanilla hg status takes 1.3 seconds. On the same system, with fsmonitor it takes about 0.3 seconds.

Tom
  • 6,325
  • 4
  • 31
  • 55
  • 1
    That looked promising until I read this: `fsmonitor will disable itself if any of the following extensions are enabled: largefiles` and we use that in our project :( But thanks, it seems like a great extension to know for any other case! – Creak Nov 07 '16 at 16:34
  • @Creak, I strongly suggest converting your largefiles repo to a plain repo and use FsMonitor. I did and I was blown away. Check out my answer http://stackoverflow.com/a/39365416/561422 with more details. – marco.m Nov 09 '16 at 08:57
  • @marco.m I'm afraid I can't do that. I'm not the owner of the repository :( – Creak Nov 09 '16 at 19:03