Wed, 15 Feb 2017 13:34:06 -0800 extdiff: log time spent in external diff program
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:34:06 -0800] rev 30982
extdiff: log time spent in external diff program We can't fix the time external diff programs take to run. Log that duration for us to remove from any stats we gather
Wed, 15 Feb 2017 13:34:06 -0800 crecord: log blocked time waiting for curses input
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:34:06 -0800] rev 30981
crecord: log blocked time waiting for curses input We want to know when we're blocked waiting for the user - log the time spent waiting in the curses keyboard handlers
Wed, 15 Feb 2017 13:38:00 -0800 ui: give editor() a tag of its own
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:38:00 -0800] rev 30980
ui: give editor() a tag of its own We know that calls to ui.editor() always block on the user's configured editor. Use a blocking tag that ensures that we don't see a huge variety of editor options in our logging.
Wed, 15 Feb 2017 13:29:12 -0800 ui: time calls to ui.system
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:29:12 -0800] rev 30979
ui: time calls to ui.system We want to know when we're blocked on ui.system, and why. Allow the user to supply a tag - otherwise we record on an unspecific tag derived from cmd.
Wed, 15 Feb 2017 13:50:06 -0800 ui: log time spent blocked on stdio
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:50:06 -0800] rev 30978
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.
Wed, 15 Feb 2017 13:07:26 -0800 contrib: add a write microbenchmark to perf.py
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:07:26 -0800] rev 30977
contrib: add a write microbenchmark to perf.py I'm adding some performance logging to ui.write - this benchmark lets us confirm that the cost of that logging is acceptably low. At this point, the microbenchmark on Linux over SSH shows: ! wall 3.213560 comb 0.410000 user 0.350000 sys 0.060000 (best of 4) while on the Mac locally, it shows: ! wall 0.342325 comb 0.180000 user 0.110000 sys 0.070000 (best of 20)
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip