On Sun, Sep 4, 2016 at 9:49 AM, Yury Selivanov <yselivanov...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
