On Sun, Sep 4, 2016 at 9:49 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote: > > > On 2016-09-03 4:13 PM, Chris Angelico wrote: >> Replace it, but only as they register themselves with a particular >> function. Imagine a profiler doing something vaguely like this: > > > "Replacing" makes it error prone to cache the pointer even for small periods > of time. Defining co_extra using Python C API forces us to acquire the GIL > etc (aside from other performance penalties). Although we probably would > recommend to use the GIL anyways, I'm not sure tuple really simplifies > anything here. If everyone behaves properly, it should be safe. tuple_pointer = co_extra max_index = len(tuple_pointer) is tuple_pointer[0] mine? No -- someone appends to the tuple -- is tuple_pointer[1] mine? No The only effect of caching is that, in effect, mutations aren't seen till the end of the iteration - a short time anyway. >> class FunctionStats: >> def __init__(self): >> self.info = [whatever, whatever, blah blah] >> >> def profile(func): >> """Decorator to mark a function for profiling""" >> func.__code__.co_extra += (FunctionStats(),) >> return func >> >> Tuple immutability impacts the initialization only. After that, you >> just iterate over it. > > > I wasn't aware we wanted to expose co_extra to Python land. I'm not > convinced it's a good idea, because exposing, say, Pyjion JIT state to > Python doesn't make any sense. At least for Python 3.6 I don't think we > would want to expose this field. > > Moreover, profiling Python with a pure Python profiler is kind of slow... > I'm sure people use C for that anyways. This is what I get for overly embracing the notion that Python is executable pseudo-code :) Yes, this would normally be happening in C, but notionally, it'll be like that. ChrisA
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4