pyrefly PyTorch 基准测试指南：基于 15k+ 文件真实代码库的 LSP 延迟与全量检查吞吐评测

pyrefly PyTorch 基准测试指南基于 15k 文件真实代码库的 LSP 延迟与全量检查吞吐评测【免费下载链接】pyreflyA fast type checker and language server for Python项目地址: https://gitcode.com/GitHub_Trending/py/pyrefly本文以 pyrefly 仓库自带的 PyTorch 基准测试套件pyrefly/benches/README.md为核心系统讲解其设计目标、代码结构、运行方式与 pin 维护流程。该套件在固定的 PyTorch 大仓 checkout15k Python 文件上覆盖交互式 LSP 延迟冷启动、错误传播、工作区符号、冷整仓批处理吞吐full_check以及冷整仓索引indexed_memory等场景是 pyrefly 用来衡量真实世界大型项目上的类型检查性能的权威手段。读完本文你将掌握如何运行这些基准、解读输出、用内存报告做对比分析以及如何安全地升级 PyTorch 版本 pin。基准测试的定位真实世界语料 vs 微基准pyrefly 的基准测试体系分为两类定位完全不同微基准micro位于 pyrefly/benches/micro.rs每个用例构建一段合成 Python 片段针对检查器的单一能力枚举成员解析、穷尽性检查、协议结构化匹配、类型收窄、渐近类型调用、类型变量 join、推断的 TypedDict、重载解析、嵌套泛型构造、Polars/pandas schema 追踪分发链等做单次内存检查计时。它是确定性、单线程的。PyTorch 真实世界基准pytorch位于 pyrefly/benches/pytorch/ 目录下在一个固定的、多 GB 的 PyTorch checkout 上跨所有核心运行衡量的是开发者在真实 IDE 中会经历的路径——线程调度、磁盘 I/O、超长冷启动都属于测量对象。这正是它与微基准的本质区别微基准回答某一处算法快不快PyTorch 基准回答打开一个真实的大项目体验快不快。两者共享 Criterion 评测框架见 pyrefly/Cargo.toml 中声明的codspeed-criterion-compat依赖但语料与目标完全不同。本文聚焦 PyTorch 真实世界基准。基准套件全景五个基准 一个内存报告整个套件共覆盖四类测量目标基准模块Criterion id测量内容衡量维度cold_start.rspytorch/cold_start_go_to_definition冷服务器 → 首次跨文件 go-to-definition首次索引时间time-to-first-index的代理error_propagation.rspytorch/error_propagation热服务器上编辑后错误传播到远端依赖文件增量重查延迟full_check.rspytorch/full_check冷整仓pyrefly check项目模式整仓批处理吞吐indexed_memory.rspytorch/indexed_memory冷整仓索引耗时索引构建时间workspace_symbol.rspytorch/workspace_symbol_init完全索引后热workspace/symbol(init)请求工作区符号查询延迟pytorch_memory/main.rs独立 target索引整仓后进程常驻内存索引内存占用它们在一个 target中发布buck 的pytorch_bench、cargo bench 的pytorch运行时通过 Criterion 的名称过滤器选择单个基准而不是为每个基准单独建 target。pytorch/main.rs 是 crate 根声明各模块并通过criterion_main!聚合五个 Criterion 组共享的 checkout 获取与 LSP 参数封装在 pytorch/common.rs 中。cold_start开发者打开项目时等待的完整路径从冷服务器出发完整走一遍开发者打开项目时会经历的路径initialize → 打开依赖图中深处的一个文件 → 完成第一次跨文件 go-to-definition。被测文件是torch/distributed/pipelining/_backward.py查询目标是其中from torch.nn import Parameter的Parameter位置由 cold_start.rs 中的PARAM_LINE/PARAM_COL常量 0 索引编码。只有当该文件及其导入闭包被分析完成后响应才能产生因此这一延迟就是首次索引时间的真实代理。实现要点cold_start.rs每个测量迭代通过BatchSize::PerIteration启动一个全新的服务器保证每个样本都是货真价实的冷启动LspInteraction在计时区外 drop服务器拆除不计入测量。使用ThreadCount::AllThreads全核运行——真实的 IDE 冷启动会并行利用 rayon 线程池这正是 time-to-first-index 应当反映的。对超大项目的首次检查可能长时间静默因此超时设置为 120 秒/1800 秒的宽裕值。若 go-to-definition 返回空结果会快速失败assert!而不是挂到超时——空结果意味着PARAM_LINE/PARAM_COL在 pin 升级后漂移了需要同步更新。error_propagation增量编辑的端到端延迟服务器已热两个文件都已打开、初始诊断已就绪prepare阶段不计时然后修改torch/nn/__init__.py将Parameter重新绑定为一个 intParameter 42测量由此产生的类型错误在多远的依赖文件_backward.py中浮现所需的时间。Iterator[Parameter]变成Iterator[int-instance]不再是类型测量以错误消息Expected a type form, got instance of \int 为判定键而不是依赖精确的诊断计数后者会随 pyrefly 版本变化。实现上有两个值得注意的细节error_propagation.rs为什么是重新绑定而不是删除导出删除Parameter as Parameter在大小写不敏感的文件系统上可能把Parameter解析到parameter.py子模块掩盖错误重新绑定则与文件系统大小写无关。打开顺序至关重要必须先打开依赖文件_backward.py并等其诊断稳定再打开源文件torch/nn/__init__.py。否则依赖文件会把torch.nn绑定到源文件的内存句柄而磁盘写入 save 触发的是文件系统句柄的invalidate_disk错误永远无法传播基准会挂死。编辑是就地写入磁盘并通过文件 watcher 通知依赖方基于已保存文件重查RestoreOnDrop保证每次迭代结束后恢复文件原样不让 PyTorch checkout 变脏。full_check冷整仓批处理吞吐与前面驱动 LSP 服务器测延迟的两个基准不同full_check 从全新State运行pyrefly check项目模式、无文件参数在 checkout 内做的每一件事发现项目、解析配置、为每个项目文件构建 handle、全核检查。full_check.rs 的关键设计FilesArgs::get(Vec::new(), ...)空文件列表即项目模式root 为当前工作目录因此基准先把进程cd进 checkout走真实的项目发现路径。依赖默认Require::Exports、被检查文件Require::Errors与 CLI 的 require level 一致见CheckArgs::get_required_levels的注释说明——若默认Errors会连依赖闭包一起错误检查测的工作量就超过真实pyrefly check了。项目文件数断言 1000该 pin 实际解析约 2.5k 个项目文件防止项目发现静默失败导致测了个空检查。black_box包裹错误收集防止被编译器优化掉。事务提交、Statedrop 都在计时区外完成。indexed_memory冷整仓索引计时将每个项目文件驱动到Require::Indexing——这是语言服务器后台索引文件所用的级别也是唯一保留 find-references 索引和每模块符号表的级别。普通批处理pyrefly check永远不会到达这一级别所以索引成本只有显式请求它的基准才能看到crates/pyrefly_bench_harness/src/lib.rs。它只计时索引持有的内存由独立的pytorch_memory目标报告。workspace_symbol热索引上的工作区符号查询先完全索引整个 checkoutsetup 阶段不计时然后测量热的workspace/symbol(init)请求的端到端延迟。初始化的查询使用IndexingMode::LazyBlocking与workspace_indexing_limit: usize::MAX并断言索引确实包含test/distributed/test_device_mesh.py中的InitDeviceMeshTestworkspace_symbol.rs 的INDEXED_SYMBOL/INDEXED_SYMBOL_FILE——这两个常量同样依赖 pin 的版本布局。所有 setup、索引和首次查询都在 Criterion 开始前完成每个样本只测量一次热的查询。为什么内存报告是独立 target而不是第五个基准pytorch_memory/main.rs 是独立二进制而非 Criterion 基准原因在文档与源码中都被反复强调RSS 是进程的属性不是例程的属性。VmRSS统计进程当前仍持有的所有内存VmHWM是进程整个生命周期的高水位标记永远不会下降。如果把它放进pytorch_bench里跑它报告的是 cold_start、error_propagation、full_check 等基准已分配的残留内存——是其中最大者的内存而不是这个索引的。一个只索引一次、不做任何别的事的进程才让这个数字名符其实。采样实现位于 crates/pyrefly_bench_harness/src/lib.rs读取/proc/self/status的VmRSS:与VmHWM:字段非 procfs 平台返回None内存报告退化为不输出而非失败。采样只是一次小文件读取几十微秒相对秒级的基准可以安全地在计时区内调用。内存是报告而非断言RSS 依赖分配器和宿主机设置阈值必然 flaky。数字的用途是比较——在两个 commit 上各跑一次diff 两个数值。该测量与语料无关、住在pyrefly_bench_harnesscrate 里因此其他语料如内部仓库的ig_indexed_memory的基准共享同一实现每个语料只提供自己的 root。PyTorch 源码 pin单点真相PyTorch 源码由 pytorch_pin.bzl 中的单个 40 位十六进制 commitrev tarball sha256固定没有 git submodule。这一个文件被BUCK加载、被共享的common模块解析所以 commit 只存在于一个地方。当前 pin 为0ab6f77f3478f367c8eab3e20a11594252356c81对应 sha2564cdd89bd...。两个 provider 为 checkout 供源common.rs内部buckpyrefly/BUCK通过http_archive从 Manifold 拉取固定的 tarball并声明为每个基准 target 的 resourcebuck 将其物化到二进制旁buck_resources在任意运行主机上报告其路径。无 github 出口流量Buck CAS 缓存它。buck_resource_root在 fbcode 构建下是强约束resource 查找失败即 panic绝不回退到 skip——因为 skip 会以 exit 0 收尾、看起来像通过这正是该函数要消灭的失败模式。OSScargo首次运行时把固定 rev 从 github 浅克隆--filterblob:none --no-checkout --depth 1fetch --depth 1到按 rev 命名的临时缓存目录std::env::temp_dir()/pyrefly-pytorch-bench-{rev}之后复用。需要git与 github.com 出口。手动覆盖设置PYREFLY_PYTORCH_BENCH_PATH指向现有 checkout 可绕过上述两者优先级最高。跳过语义checkout 无法获得时如无 git、无出口、无覆盖路径基准打印跳过通知并以 0 退出cargo bench在裸 checkout 中仍可正常工作。缓存以torch/nn/__init__.py哨兵文件判定完整性克隆先进 staging 目录、成功后 rename 到位杜绝中断克隆留下半成品被当作有效 checkout。运行方式与实用参数构建模式决定一切必须用优化构建否则数字毫无意义Buck 用fbcode//mode/opt最终数字用fbcode//mode/opt-clang-thinltocargo bench默认就使用优化的 bench profile。Debug 构建慢 3-10 倍不可比较。绝不要并行跑两个基准。完整命令参考# 全部基准 buck2 run fbcode//mode/opt fbcode//pyrefly/pyrefly:pytorch_bench -- --bench cargo bench --bench pytorch # 只跑一个用 Criterion 名称过滤器选择 buck2 run fbcode//mode/opt fbcode//pyrefly/pyrefly:pytorch_bench -- --bench cold_start buck2 run fbcode//mode/opt fbcode//pyrefly/pyrefly:pytorch_bench -- --bench error_propagation buck2 run fbcode//mode/opt fbcode//pyrefly/pyrefly:pytorch_bench -- --bench full_check buck2 run fbcode//mode/opt fbcode//pyrefly/pyrefly:pytorch_bench -- --bench indexed_memory PYREFLY_LOGoff buck2 run fbcode//mode/opt fbcode//pyrefly/pyrefly:pytorch_bench -- --bench workspace_symbol_init cargo bench --bench pytorch -- cold_start cargo bench --bench pytorch -- error_propagation cargo bench --bench pytorch -- full_check cargo bench --bench pytorch -- indexed_memory PYREFLY_LOGoff cargo bench --bench pytorch -- workspace_symbol_init # 内存报告 —— 独立 target以获得干净的进程 buck2 run fbcode//mode/opt fbcode//pyrefly/pyrefly:pytorch_memory_bench cargo bench --bench pytorch_memory注意两种构建工具的参数位置差异buck 的额外参数追加在--之后cargo 直接传递。workspace_symbol_init前加PYREFLY_LOGoff是为避免日志输出干扰测量。有用 flagsbuck 追加在--后cargo 直接传--list—— 列出二进制中的基准而不实际运行。--quick—— 更快、置信度更低的运行。--noplot—— 跳过 Criterion 报告渲染。无头 devserver 且无 gnuplot、无可用字体时必需否则 plotters 后端会在基准结束后以BackendError(FontError(FontUnavailable))panic计时结果不受影响。时间预算与 CI 定位这些是重量级 walltime 基准每个约 2-4 分钟Criterion 样本下限 10 个冷启动每次迭代约 3-5 秒错误传播 warmup 后每次约 2-3 秒full_check 每次约 1-1.5 秒。它们是手动的/重量级的默认不进入 CI Sandcastlehttp_archive依赖被标记为manual。Criterion 强制至少 10 个样本低于会 panic这些重量级基准都使用下限 10。输出位置Criterion 写入target/criterion/HTML 图、CSV 样本、estimates.json。由于 buck run / cargo bench 从 cell 根运行实际落在仓库根目录的target/criterion/。它是一次性产物不要提交也不要添加仓库根 ignore 条目已被恰当地 gitignore。升级 pin 的完整流程在有 github 出口的机器上devvm/Sandcastle 默认无出口./update_revision.sh 40-hex-shaupdate_revision.sh 的执行序列校验参数为 40 位十六进制浅克隆--filterblob:none --depth 1 fetch checkout 该 rev 到临时目录trap保证失败时清理。git archive --formattar.gz --prefixpytorch/打包无.git计算 sha256优先sha256sum回退shasum -a 256。仅当 tarball 已存在后才改写 pytorch_pin.bzl 中的两行常量用 python 正则改写规避 BSD/GNU sed 差异——失败的 clone/fetch 不会留下引用了未上传产物的 pin。将 tarball 上传到 Manifoldpyrefly_resources/tree/无 manifold CLI 时打印重试指引。打印后续步骤review pin 变更、buck2 uquery验证 target 可解析、提交。升级后必须复检两处硬编码README 明确警告PARAM_LINE/PARAM_COLcold_start.rs 编码了_backward.py中Parameter的位置。INDEXED_SYMBOL/INDEXED_SYMBOL_FILEworkspace_symbol.rs 的索引符号名与文件路径依赖 pin 版本。漏掉任一处的后果是基准快速失败cold_start 的 assert或断言索引不含目标符号从而暴露漂移——这正是这些断言存在的意义。小结把真实世界性能变成可复现的测量这套 PyTorch 基准把大项目上的类型检查体验拆成了五个可复现的测量维度冷启动首次索引cold_start、增量错误传播error_propagation、整仓批处理吞吐full_check、整仓索引构建indexed_memory与热索引上的工作区符号查询workspace_symbol外加一个严格独立的进程内存报告pytorch_memory。其设计处处体现测量严谨性单点 pin 消除语料漂移、BatchSize::PerIteration保证每个样本都是真冷启动、计时区外 drop 排除拆除开销、RSS 的进程属性决定独立 target、内存只做对比不做断言。对于想要深入基准代码的读者建议从 pytorch/common.rscheckout 获取与 LSP 参数与 crates/pyrefly_bench_harness/src/lib.rs索引与内存报告共享实现入手再逐个阅读五个基准模块。【免费下载链接】pyreflyA fast type checker and language server for Python项目地址: https://gitcode.com/GitHub_Trending/py/pyrefly创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考