On 9/21/16, 7:41 AM, "Yuya Nishihara" <y...@tcha.org> wrote:
On Tue, 20 Sep 2016 21:49:26 +0900, Yuya Nishihara wrote:
> On Mon, 19 Sep 2016 16:13:56 -0700, Arun Kulshreshtha wrote:
> > # HG changeset patch
> > # User Arun Kulshreshtha <kulsh...@fb.com>
> > # Date 1474324901 25200
> > # Mon Sep 19 15:41:41 2016 -0700
> > # Node ID 679c90104cc1fc92099ede6bd359f6ab5b10640d
> > # Parent 285a8c3e53f2183438f0cdbc238e4ab851d0d110
> > profiling: allow nested usage of maybeprofile
> > Add a check to the maybeprofile context manager to ensure that profiling
> > is only enabled once in nested invocations of this context manager.
> > Updated in v2 of this patch to reset itself once the root invocation
> > has exited. While not currently used, this ensures that maybeprofile
> > can be used in multiple (non-nested) places in a single run.
> > diff --git a/mercurial/profiling.py b/mercurial/profiling.py
> > --- a/mercurial/profiling.py
> > +++ b/mercurial/profiling.py
> > @@ -157,8 +157,15 @@
> > just use a single code path for calling into code you may want to
> > and this function determines whether to start profiling.
> > """
> > - if ui.configbool('profiling', 'enabled'):
> > +
> > + # Guard against nested invocations of this context manager.
> > + # Profiling should only be started in the outermost invocation.
> > + alreadyenabled = getattr(maybeprofile, 'enabled', False)
> > +
> > + if ui.configbool('profiling', 'enabled') and not alreadyenabled:
> > + maybeprofile.enabled = True
> > with profile(ui):
> > yield
> > + maybeprofile.enabled = False
> maybeprofile() can be called in threads. If we need to prevent nesting,
> have to save the flag in TLS.
That said, I'm not sure if nested maybeprofile() can be noop. Last time,
tried to make statprof stackable, which would imply maybeprofile() designed
to be nested.
Hm, right now it seems like if you stack profilers, you’ll get multiple
profiling statistics printouts at the end of command execution, which is hard
to read. But this this behavior is actually desirable, then we’ll need to deal
with this situation differently.
Mercurial-devel mailing list