You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A common way to implement operating systems is via generator functions cached to global. Right now, decorating the definition with @profile results in the generation creation being profiled, but it does not profile what we actually care about, which is the .next() (or .throw() or .return()) invocation runtimes.
I'm proposing an @profileGenerator decorator, which is meant to be applied to generator functions and will patch the .next, .return, and .throw methods on the returned generator object with profiling versions, and recording the runtimes as fnName, fnName#return, and fnName#throw, respectively.
I could whip up a PR for this in about a week or so.
The text was updated successfully, but these errors were encountered:
A common way to implement operating systems is via generator functions cached to global. Right now, decorating the definition with
@profile
results in the generation creation being profiled, but it does not profile what we actually care about, which is the.next()
(or.throw()
or.return()
) invocation runtimes.I'm proposing an
@profileGenerator
decorator, which is meant to be applied to generator functions and will patch the.next
,.return
, and.throw
methods on the returned generator object with profiling versions, and recording the runtimes asfnName
,fnName#return
, andfnName#throw
, respectively.I could whip up a PR for this in about a week or so.
The text was updated successfully, but these errors were encountered: