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.
Chiaki
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
