Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

`are_co_aligned` is tokenizing too greedily causing to be possibly slow

未关闭
#907 7 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

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

调研方向

先从 dask_expr/_expr.py 中 are_co_aligned 附近的第 2863-2874 行开始,然后在更大的数据集上复现 issue 中描述的 parquet_reader 优化基准测试。检查 tokenization 和 Expr set 如何影响 optimize 步骤,并验证完成的更改能够避免 slowdown 和不安全的 set 行为,同时不改变 alignment 结果。

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

描述

The utility function are_co_aligned, see

https://github.com/dask-contrib/dask-expr/blob/9334e062a7b41161977ca1c42176197629569cc5/dask_expr/_expr.py#L2863-L2874

is unfortunately rather slow due to the tokenization and lack of caching. in paruqet_reader benchmarks on larger datasets, I saw this slowing down the optimize step by almost a second (when using pyarrowFS such that filters are pushed down

image

On top of this, I believe the implementation is unsafe since it is putting Expr objects into a set. Sets and dicts are requiring both __hash__ and __eq__ to be implemented and working as the stdlib protocol defines them. While this is true for hash (it hashes the name, this is not the case for __eq__ since this just creates another Expr instance instead of returning a bool. I suspect this just tells how the set is redundant if there hasn't been ever a hash collision / duplicate object here.

主要语言
Python
星标
89
派生
26
PR 合并指标
30 天内没有已合并 PR

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

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

dask/dask-expr 的其他 Issue

查看 dask/dask-expr 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

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