[Python-Dev] Update on PEP 523 and adding a co_extra field to code objects (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Sat Sep 3 12:09:31 EDT 2016
- Previous message (by thread): [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects
- Next message (by thread): [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3 September 2016 at 08:50, Chris Angelico <rosuav at gmail.com> wrote:
Got it, thanks. I hope the vagaries of linear search don't mess with profilers - a debugger isn't going to be bothered by whether it gets first slot or second, but profiling and performance might get subtle differences based on which thing looks at a function first. A dict would avoid that (constant-time lookups with a pre-selected key will be consistent), but costs a lot more.
Profiling with a debugger enabled is going to see a lot more interference from the debugger than it is from a linear search through a small tuple for its own state :)
Optimising compilers and VM profilers are clearly a case where cooperation will be desirable, as are optimising compilers and debuggers. However, that cooperation is still going to need to be worked out on a pairwise basis - the PEP can't magically make arbitrary pairs of plugins compatible, all it can do is define some rules and guidelines that make it easier for plugins to cooperate when they want to do so.
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message (by thread): [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects
- Next message (by thread): [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]