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.
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).
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.
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.
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.
Augie Fackler <augie@google.com> [Mon, 15 Aug 2016 12:26:02 -0400] rev 29780
merge with stable