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)
Wed, 15 Feb 2017 13:17:45 -0800 ui: provide a mechanism to track and log blocked time
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:17:45 -0800] rev 30976
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.
Wed, 15 Feb 2017 13:17:39 -0800 mercurial: switch to util.timer for all interval timings
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 13:17:39 -0800] rev 30975
mercurial: switch to util.timer for all interval timings util.timer is now the best available interval timer, at the expense of not having a known epoch. Let's use it whenever the epoch is irrelevant.
Wed, 15 Feb 2017 11:53:59 -0800 util: introduce timer()
Simon Farnsworth <simonfar@fb.com> [Wed, 15 Feb 2017 11:53:59 -0800] rev 30974
util: introduce timer() As documented for timeit.default_timer, there are better timers available for performance measures on some platforms. These timers don't have a set epoch, and thus are only useful for interval measurements, but have higher resolution, and thus get you a better measurement overall. Use the same selection logic as Python's timeit.default_timer. This is a platform clock on Python 2 and early Python 3, and time.perf_counter on Python 3.3 and later (where time.perf_counter is introduced as the best timer to use).
Thu, 22 Dec 2016 02:38:53 +0100 color: move the '_render_effects' function to the core module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 02:38:53 +0100] rev 30973
color: move the '_render_effects' function to the core module
Thu, 22 Dec 2016 02:37:18 +0100 color: move '_effect_str' function into the core module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 02:37:18 +0100] rev 30972
color: move '_effect_str' function into the core module
Thu, 22 Dec 2016 02:34:22 +0100 color: move configstyles into the core module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 02:34:22 +0100] rev 30971
color: move configstyles into the core module The extension is getting thinner as we speak!
Thu, 22 Dec 2016 02:30:03 +0100 color: rework conditional 'valideffect'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 02:30:03 +0100] rev 30970
color: rework conditional 'valideffect' Not very important, but the full conditional is not that hard to follow and having it unified make the function role a bit clearer in my opinion.
Thu, 22 Dec 2016 02:26:50 +0100 color: move 'valideffect' function into the core module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 02:26:50 +0100] rev 30969
color: move 'valideffect' function into the core module
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip