python / python/cpython

Avoid creating temporary objects in BINARY_SLICE

未关闭
#144,569 9 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

interpreter-core topic-JIT type-feature
主要语言
Python
星标
77.2k
派生
35.9k
PR 合并指标
PR 指标待抓取

描述

Feature or enhancement

Proposal:

Currently BINARY_SLICE looks like this:

        op(_BINARY_SLICE, (container, start, stop -- res)) {
            PyObject *slice = _PyBuildSlice_ConsumeRefs(PyStackRef_AsPyObjectSteal(start),
                                                        PyStackRef_AsPyObjectSteal(stop));
            PyObject *res_o;
            if (slice == NULL) {
                res_o = NULL;
            }
            else {
                res_o = PyObject_GetItem(PyStackRef_AsPyObjectBorrow(container), slice);
                Py_DECREF(slice);
            }
            PyStackRef_CLOSE(container);
            ERROR_IF(res_o == NULL);
            res = PyStackRef_FromPyObjectSteal(res_o);
        }

Note that we build a slice just for getitem, only to throw it away immediately after.

We can scalar replace the slice in BINARY_SLICE after recording the types. If we record the container type, we can call the slice dispatcher underneath directly without boxing the slice object. See for example BINARY_OP_SUBSCR_LIST_SLICE

We'd need to guard on the type recorded.

I propose to do this in the current optimizer pass rather than the partial evaluation pass, as this is just a simple optimization within a single op, while the PE pass can handle inter-instruction optimization.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs
  • gh-144590
  • gh-156318

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

从 BINARY_SLICE 入口点开始,并将其与当前优化器 pass 中的 BINARY_OP_SUBSCR_LIST_SLICE 进行比较;同时阅读部分求值 pass,以理解所述边界。完成的标志是记录的容器类型受到保护,并且切片分派避免创建临时切片对象,同时保持行为不变。

由索引模型根据 Issue 内容生成。

评估

技术栈
c, python
领域
compilers, performance
Issue 类型
功能
难度
4/5
预计耗时
3-5 天
活跃度
停滞
描述清晰度
基本清楚
新手友好度
30/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。