Commit Graph

10 Commits

Author SHA1 Message Date
Boris Feld
a8b4456e5c configitems: register the test 'logtoprocess.foo' config 2017-10-13 23:46:37 +02:00
Jun Wu
5c5bc340e6 test-logtoprocess: make it compatible with chg
chg runs more commands and outputs more lines. This patch matches them.

Differential Revision: https://phab.mercurial-scm.org/D914
2017-10-02 18:22:43 -07:00
Augie Fackler
c9814ada51 tests: update test-logtoprocess to pass our import checker 2017-08-22 16:58:28 -04:00
Pulkit Goyal
b4347ea80f py3: make sure commands name are bytes in tests 2017-06-25 08:20:05 +05:30
Matt Harbison
75459d443c test-logtoprocess: don't run on Windows
Several bits of output were missing[1], unless the DETACHED_PROCESS flag is
_not_ passed to subprocess.Popen().  The problem with that is it briefly opens
and closes several cmd.exe windows on screen.  Foozy also mentioned some other
issues in that thread.

With this, the last of the long standing Windows failures fixed, the test suite
now runs cleanly (536 ran, 67 skipped) on Windows 7 x64, with python 2.7.13. \o/

[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096987.html
2017-06-19 21:44:23 -04:00
Yuya Nishihara
3e663dde68 registrar: move cmdutil.command to registrar module (API)
cmdutil.command wasn't a member of the registrar framework only for a
historical reason. Let's make that happen. This patch keeps cmdutil.command
as an alias for extension compatibility.
2016-01-09 23:07:20 +09:00
Jun Wu
77eeb280fa test-logtoprocess: use cat to wait for outputs
Commands started by logtoprocess are running asynchronously. To be able to
test the output, we need to block and wait for the output.

The patch uses "| cat" to wait for such "asynchronous" outputs, to make the
test more reliable. I have also written a short notice at the top, hopefully
people would be aware of the pitfall when changing the test.
2017-02-16 10:33:59 -08:00
Simon Farnsworth
2172b7713c ui: log time spent blocked on stdio
We use a wrapper around Mercurial at Facebook that logs key statistics (like
elpased time) to our standard performance tooling.

This is less useful than it could be, because we currently can't tell when a
command is slow because we need to fix Mercurial versus when a command is
slow because the user isn't interacting quickly.

Teach Mercurial to log the time it spends blocked, so that our tooling can
pick it up and submit it with the elapsed time - we can then do the math in
our tooling to see if Mercurial is slow, or if the user simply failed to
interact.

Combining this with the command duration log means that we can ensure that
we concentrate performance efforts on the things that bite Facebook users.

The perfwrite microbenchmark shifts from:
Linux:
! wall 3.213560 comb 0.410000 user 0.350000 sys 0.060000 (best of 4)
Mac:
! wall 0.342325 comb 0.180000 user 0.110000 sys 0.070000 (best of 20)

before this change to:
! wall 3.478070 comb 0.500000 user 0.420000 sys 0.080000 (best of 3)
Mac:
! wall 0.218112 comb 0.220000 user 0.150000 sys 0.070000 (best of 15)

showing a small hit in comb time, but firmly in the noise on wall time.
2017-02-15 13:50:06 -08:00
Simon Farnsworth
bd8f9eccad ui: provide a mechanism to track and log blocked time
We want to log the time Mercurial spends trapped in things outside
programmatic control. Provide a mechanism to give us both command runtime
and as many different sources of blocking as we deem useful.
2017-02-15 13:17:45 -08:00
Martijn Pieters
7d4b1c457a logtoprocess: new experimental extension
This extension lets you direct specific ui.log() information to shell
commands, spawned in the background. This can be used to, say, capture
timings, commandfailure tracebacks, etc., making the output available
to other command-line tools.
2016-04-05 17:39:59 +01:00