On Mon, 1 Feb 2016 at 12:16 Yury Selivanov <yselivanov...@gmail.com> wrote:
> Brett, > > On 2016-02-01 3:08 PM, Brett Cannon wrote: > > > > > > On Mon, 1 Feb 2016 at 11:51 Yury Selivanov <yselivanov...@gmail.com > > <mailto:yselivanov...@gmail.com>> wrote: > > > > Hi Brett, > > > [..] > > > > > > The first two fields are used to make sure that we have objects of > the > > same type. If it changes, we deoptimize the opcode immediately. > Then > > we try the offset. If it's successful - we have a cache hit. If > not, > > that's fine, we'll try another few times before deoptimizing the > > opcode. > > > > > > So this is a third "next step" that has its own issue? > > It's all in issue http://bugs.python.org/issue26219 right now. > > My current plan is to implement LOAD_METHOD/CALL_METHOD (just opcodes, > no cache) in 26110. > > Then implement caching for LOAD_METHOD, LOAD_GLOBAL, and LOAD_ATTR in > 26219. I'm flexible to break down 26219 in three separate issues if > that helps the review process (but that would take more of my time): > > - implement support for opcode caching (general infrastructure) + > LOAD_GLOBAL optimization > - LOAD_METHOD optimization > - LOAD_ATTR optimization > I personally don't care how you break it down, just trying to keep all the moving pieces in my head. :) Anyway, it sounds like PEP 509 is blocking part of it, but the LOAD_METHOD stuff can go in as-is. So are you truly blocked only on getting the latest version of that patch up to http://bugs.python.org/issue26110 and getting a code review?
_______________________________________________ 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
