On Sat, Aug 6, 2016 at 10:16 PM, ISHIKAWA,chiaki <ishik...@yk.rim.or.jp> wrote:
> Thank you for the tips. > > More comments inline. > > On 2016/08/07 2:52, Gregory Szorc wrote: > >> On Fri, Aug 5, 2016 at 7:36 PM, ISHIKAWA,chiaki <ishik...@yk.rim.or.jp >> <mailto:ishik...@yk.rim.or.jp>> wrote: >> >> Hi, >> >> I am patching, compiling and testing C-C TB locally under linux >> (inside a virtualbox). >> >> I have noticed that hg "qpush -a", "hg qpop -a", "hg identity" seems >> to have slow down considerably after I installed |watchman| based on >> the suggestion from the output of "mozilla/mach mercurial setup". >> >> Has anyone noticed this? >> >> Debian GNU/Linux: uname -a output is >> Linux ip030 3.19.5 #1 SMP Mon Apr 20 08:50:21 JST 2015 x86_64 >> GNU/Linux >> CPU is (from dmesg) >> [ 0.044782] smpboot: CPU0: Intel(R) Xeon(R) CPU E3-1240 V2 @ >> 3.40GHz (fam: 06, model: 3a, stepping: 09) >> >> and I have allocated four (4) CPUs to this virtualbox image. >> >> >> I have not noticed this. >> >> When watchman first initializes, it needs to scan your entire directory >> tree before it can return results. Watchman doesn't initialize until >> running a `hg` command that needs watchman. So the first `hg` command >> that uses watchman will take a bit longer. There is another scenario >> where hg is unable to talk to watchman, hits an error or timeout, then >> falls back to the non-watchman code path. I see this all the time on >> Windows or when my page cache is empty and watchman is unable to crawl >> the source directory before hg times out waiting for data. A warning is >> printed in this case, however. >> >> Does `hg status` speed up with watchman installed? On my machine, there >> is a somewhat significant difference between a fresh watchman state: >> >> $ kill <pid of watchman process> >> $ time hg status >> real 0m1.334s >> >> After watchman is fully initialized: >> >> $ time hg status >> real 0m0.059s >> >> And without watchman integration: >> >> $ time hg --config extensions.fsmonitor=! status >> real 0m0.645s >> >> If you aren't seeing speedup from a fully initialized watchman, either >> your repo is too small to benefit from watchman or something is wrong >> with watchman or the hg watchman bridge. Be sure you are using Mercurial >> 3.8+, the "fsmonitor" extension (it replaces the 3rd party hgwatchman >> extension), and a modern version of watchman. `mach mercurial-setup` >> will ensure you are using "fsmonitor" if running hg 3.8+. >> > > Something is wrong. > Even a simple hg identfiy takes a long time... > > With fsmonitor= in ~/.hgrc > > !! > time hg identify > 76d36e595ece qtip/tip/trychooser.patch > > real 0m13.959s > user 0m13.424s > sys 0m0.512s > > Without > ishikawa@ip030:/NREF-COMM-CENTRAL/comm-central$ time hg identify > 76d36e595ece qtip/tip/trychooser.patch > > real 0m0.115s > user 0m0.092s > sys 0m0.020s > ishikawa@ip030:/NREF-COMM-CENTRAL/comm-central$ > > Notice the "x 100" slowdown. > > One thing to note: > C-C tree contains a SEPARATE M-C tree under ./mozilla subdirectory AND > this M-C subtree is NOT managed by the top-level C-C hg repository. > These are two separate repositories. > But it looks that when I run |hg| command at C-C top-level, > the fsmonitor feature looks into the UNRELATED ./mozilla subdirectory, > which itself is HUGE, and it seems to waste time to look up the changes in > THAT subdirectory. Oh well. > > I thinnk fsmonitor extension may not work well with such overlaid > independent repositories. > Consider reporting an upstream issue. Instructions at https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/issues.html If you include output from `hg --profile` to prove the slowdown is in fsmonitor, you'll definitely get people's attention.
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
