(original) (raw)

Brett,

On 2016-02-01 3:08 PM, Brett Cannon wrote:
\>
\>
\> On Mon, 1 Feb 2016 at 11:51 Yury Selivanov <yselivanov.ml@gmail.com
\> yselivanov.ml@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