Sun, 14 Aug 2016 18:28:43 -0700 profiling: don't error with statprof when profiling has already started
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 14 Aug 2016 18:28:43 -0700] rev 29785
profiling: don't error with statprof when profiling has already started statprof.reset() asserts if profiling has already started. So don't call if it profiling is already running.
Sun, 14 Aug 2016 17:51:12 -0700 profiling: add a context manager that no-ops if profiling isn't enabled
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 14 Aug 2016 17:51:12 -0700] rev 29784
profiling: add a context manager that no-ops if profiling isn't enabled And refactor dispatch.py to use it. As you can see, the resulting code is much simpler. I was tempted to inline _runcommand as part of writing this series. However, a number of extensions wrap _runcommand. So keeping it around is necessary (extensions can't easily wrap runcommand because it calls hooks before and after command execution).
Sun, 14 Aug 2016 18:25:22 -0700 profiling: make profiling functions context managers (API)
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 14 Aug 2016 18:25:22 -0700] rev 29783
profiling: make profiling functions context managers (API) This makes profiling more flexible since we can now call multiple functions when a profiler is active. But the real reason for this is to enable a future consumer to profile a function that returns a generator. We can't do this from the profiling function itself because functions can either be generators or have return values: they can't be both. So therefore it isn't possible to have a generic profiling function that can both consume and re-emit a generator and return a value.
Sun, 14 Aug 2016 16:35:58 -0700 dispatch: set profiling.enabled when profiling is enabled
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 14 Aug 2016 16:35:58 -0700] rev 29782
dispatch: set profiling.enabled when profiling is enabled We do this for other global command arguments. We don't for --profile for reasons that are unknown to me. Probably because nobody has needed it. An upcoming patch will introduce a new consumer of the profiling code. It doesn't have access to command line arguments. So let's set the config option during argument processing. We also remove a check for "options['profile']" because it is now redundant.
Sun, 14 Aug 2016 16:30:44 -0700 profiling: move profiling code from dispatch.py (API)
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 14 Aug 2016 16:30:44 -0700] rev 29781
profiling: move profiling code from dispatch.py (API) Currently, profiling code lives in dispatch.py, which is a low-level module centered around command dispatch. Furthermore, dispatch.py imports a lot of other modules, meaning that importing dispatch.py to get at profiling functionality would often result in a module import cycle. Profiling is a generic activity. It shouldn't be limited to command dispatch. This patch moves profiling code from dispatch.py to the new profiling.py. The low-level "run a profiler against a function" functions have been moved verbatim. The code for determining how to invoke the profiler has been extracted to its own function. I decided to create a new module rather than stick this code elsewhere (such as util.py) because util.py is already quite large. And, I foresee this file growing larger once Facebook's profiling enhancements get added to it.
Mon, 15 Aug 2016 12:26:02 -0400 merge with stable
Augie Fackler <augie@google.com> [Mon, 15 Aug 2016 12:26:02 -0400] rev 29780
merge with stable
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip