ty 基准测试深度解析CLI 全量检查与语言服务器增量的真实性能数据【免费下载链接】tyAn extremely fast Python type checker and language server, written in Rust.项目地址: https://gitcode.com/GitHub_Trending/ty2/ty本篇技术指南以仓库根目录下的 BENCHMARKS.md 为唯一主体完整呈现 ty一款用 Rust 编写的极速 Python 类型检查器与语言服务器在 macOS Apple M3 Max 平台、9 个真实开源项目上的官方基准测试结果覆盖 CLI 全量类型检查、LSP 增量编辑与诊断获取三大场景并对比 Pyrefly、Pyright、mypy 三款主流工具。读完本文你将能够准确理解 ty 的官方性能数据、复现测试的方法要点以及正确解读这些数字所代表的工程含义。测试环境与方法概述所有基准测试均在macOSApple M3 Max 16 核128 GB 内存上计算得出参与对比的工具及版本如下工具版本语言/形态ty0.0.55RustPyPI 发布Pyrefly1.1.1PythonPyPI 发布Pyright1.1.410Node.jsnpm 发布mypy2.1.0PythonPyPI 发布需要强调的是基准性能会因操作系统而异、因项目而异。因此该文档特意选取了多个不同类型、不同规模的真实项目作为测试样本以尽量代表真实世界的使用形态包括代码格式化/静态分析类Black、isortWeb 框架/库discord.py、Jinja智能家居大型单体项目Home Assistant数据科学/数值计算pandas、pandas-stubs、PyTorch工作流编排Prefect测试覆盖两大维度一是CLIty check全量类型检查的端到端耗时使用 hyperfine 风格多次运行取均值二是LSP语言服务器的增量编辑与获取诊断两项交互使用 pytest-benchmark 输出。关于基准测试的运行说明原文档给出了明确指引ty_benchmark/README.md下文将结合仓库内相关文档逐项展开。CLI 基准测试全量类型检查的端到端耗时CLI 部分使用多次运行取均值的计时方式输出形如Time (mean ± σ)、Range (min … max)与运行次数runs。每个工具均出现Warning: Ignoring non-zero exit code.的提示——这是因为类型检查器在发现类型错误时会以非零退出码结束hyperfine 对此给出警告但不影响计时结果的有效性。逐项目原始数据以 black 项目为例原始输出完整保留了每次基准的细节black ----- Benchmark 1: ty Time (mean ± σ): 69.5 ms ± 1.6 ms [User: 530.8 ms, System: 34.8 ms] Range (min … max): 65.7 ms … 73.6 ms 40 runs Warning: Ignoring non-zero exit code. Benchmark 2: Pyrefly Time (mean ± σ): 128.3 ms ± 2.5 ms [User: 465.1 ms, System: 53.0 ms] Range (min … max): 123.4 ms … 134.3 ms 23 runs Warning: Ignoring non-zero exit code. Benchmark 3: mypy Time (mean ± σ): 1.316 s ± 0.012 s [User: 1.216 s, System: 0.092 s] Range (min … max): 1.303 s … 1.336 s 10 runs Benchmark 4: Pyright Time (mean ± σ): 1.420 s ± 0.010 s [User: 18.088 s, System: 0.981 s] Range (min … max): 1.404 s … 1.433 s 10 runs Warning: Ignoring non-zero exit code. Summary ty ran 1.85 ± 0.06 times faster than Pyrefly 18.94 ± 0.46 times faster than mypy 20.45 ± 0.49 times faster than Pyright可以看到该输出中还包含User用户态 CPU 时间与System内核态 CPU 时间信息。值得注意的细节是Pyright 的User时间如 black 中的 18.088 s远超其墙钟时间1.420 s说明其大量工作由并行/后台进程完成而 ty 的User时间530.8 ms与墙钟时间69.5 ms的比例相对更接近反映了其 CPU 调度特征与 Pyright 存在本质差异。全部项目结果汇总将文档中 9 个项目的 CLI 均值与加速比整理如下均值均为mean ± σσ 为标准差项目tyPyreflymypyPyrightty vs Pyreflyty vs mypyty vs Pyrightblack69.5 ms ± 1.6128.3 ms ± 2.51.316 s ± 0.0121.420 s ± 0.0101.85×18.94×20.45×discord.py144.1 ms ± 4.9193.4 ms ± 5.02.538 s ± 0.0243.556 s ± 0.0611.34×17.61×24.68×homeassistant1.812 s ± 0.0332.550 s ± 0.03924.601 s ± 0.14123.410 s ± 0.4831.41×13.57×12.92×isort82.3 ms ± 1.6109.6 ms ± 1.5679.4 ms ± 10.62.240 s ± 0.0121.33×8.26×27.22×jinja69.5 ms ± 1.4105.0 ms ± 1.9762.7 ms ± 6.41.324 s ± 0.0141.51×10.97×19.05×pandas428.0 ms ± 18.0752.5 ms ± 15.413.089 s ± 0.0417.512 s ± 0.0761.76×30.58×17.55×pandas-stubs94.4 ms ± 3.3205.9 ms ± 1.96.971 s ± 0.0802.201 s ± 0.0132.18×73.86×23.32×prefect113.1 ms ± 4.8242.0 ms ± 8.8701.4 ms ± 10.34.208 s ± 0.0402.14×6.20×37.22×pytorch1.216 s ± 0.0421.492 s ± 0.02528.227 s ± 0.07416.885 s ± 0.5051.23×23.22×13.89×注homeassistant 一行的加速比顺序为ty vs Pyrefly、ty vs Pyright、ty vs mypy原始文档中该项目的 Summary 顺序为 Pyrefly → Pyright → mypy表中已按统一列序排列数值均来自原文。数据解读要点从上述数据可以观察出几个一致的模式ty 在所有 9 个项目上均快于全部三个对比工具对 Pyrefly 的领先幅度在 1.23×pytorch到 2.18×pandas-stubs之间。对 mypy 与 Pyright 的领先幅度随项目规模与特性剧烈波动在类型标注密度极高、stub 文件繁多的 pandas-stubs 上ty 相对 mypy 达到73.86×而在小型的 isort 上相对 mypy 为 8.26×。大型项目上的绝对收益最显著homeassistant 的 mypy 需 24.601 s、Pyright 需 23.410 s而 ty 仅需 1.812 s——意味着一次完整的 CI 类型检查可以从半分钟量级压缩到亚两秒量级pytorch 上 mypy 需要 28.227 sty 仅 1.216 s。标准差σ整体较小说明各工具在重复运行下表现稳定pandas-stubs 的 mypy 结果被标记为检测到统计离群值建议在安静的系统上重跑这是唯一出现该提示的条目。如何自行复现 CLI 基准ty 的 CLI 基准本质上就是一次无缓存的完整类型检查。你可以在任何项目上快速体验 ty 的全量检查耗时使用 uvx 免安装运行uvx ty check默认会检查工作目录或项目根目录下的所有 Python 文件见 docs/index.md。更细粒度的控制可参考 CLI 参考文档ty check支持--excludegitignore 风格排除模式如tests/、**/__pycache__/**、--config-file指定ty.toml配置文件路径也可通过TY_CONFIG_FILE环境变量设置、--color控制彩色输出auto/always/never等选项可用于构造与官方基准一致的检查范围与输出行为。需要特别说明官方基准的完整复现脚本含项目拉取、工具安装、对比编排由原文档指向ty_benchmark/README.md而当前仓库ruff/ 子模块尚未包含该脚本内并不存在可直接执行的基准脚本因此本文不提供逐行复现步骤仅还原官方文档已公布的数据与方法。LSP 基准测试编辑器内交互的核心指标对于语言服务器而言单次全量检查的速度并非唯一指标——开发者在编辑器中更关心每次击键/保存后的响应延迟。BENCHMARKS.md 的 LSP 部分使用 pytest-benchmark 输出覆盖两个典型场景每个测试运行 10 轮Rounds、每轮 1 次迭代Iterations。表格中各列含义Min/Max/Mean/Median毫秒、StdDev标准差、IQR四分位距、Outliers离群值格式高值;低值、OPS每秒操作数括号内为相对 ty 的比值。场景一增量编辑Incremental edit该场景模拟在编辑器中打开文件并做小幅修改后服务器完成一次增量重新分析所需的时间。原始输出示例blackName (time in ms) Min Max Mean StdDev Median IQR Outliers OPS Rounds Iterations test_incremental_edit[black-ty] 13.5952 (1.0) 14.7028 (1.0) 14.0826 (1.0) 0.3919 (1.0) 13.9682 (1.0) 0.4927 (1.0) 4;0 71.0096 (1.0) 10 1 test_incremental_edit[black-pyrefly] 71.4268 (5.25) 99.0502 (6.74) 85.6680 (6.08) 7.9382 (20.25) 84.9140 (6.08) 12.2150 (24.79) 2;0 11.6730 (0.16) 10 1 test_incremental_edit[black-pyright] 475.1242 (34.95) 492.5708 (33.50) 483.2225 (34.31) 4.7892 (12.22) 483.9335 (34.65) 4.6348 (9.41) 3;1 2.0694 (0.03) 10 1全部项目均值汇总单位ms项目tyPyreflyPyrightty 相对 Pyreflyty 相对 Pyrightblack14.0885.67483.226.08×34.31×discord.py18.9986.52504.864.56×26.59×homeassistant27.3286.96565.543.18×20.70×isort21.5351.77418.882.40×19.45×jinja16.0073.74495.644.61×30.97×pandas57.91231.22612.203.99×10.57×prefect6.8257.13642.578.37×94.18×pytorch3.7826.45408.117.00×107.97×增量编辑场景的亮点数据在 prefect 上 ty 均值仅6.82 ms在 pytorch 上仅3.78 ms而 Pyright 在同样的编辑操作上分别需要 642.57 ms 与 408.11 ms——这意味着在 Pyright 中等待诊断反馈的时间内ty 理论上可以完成上百次增量更新。这一表现与 README.md 中强调的fine-grained incremental analysis细粒度增量分析设计目标直接对应ty 的 LSP 被专门设计为在 IDE 中编辑文件时提供快速更新而非每次整体重算。场景二获取诊断Fetch diagnostics该场景模拟文件首次打开或保存后服务器计算并返回全部诊断信息包括类型错误、提示等的耗时。原始输出示例blacktest_fetch_diagnostics[black-ty] 50.0127 (1.0) 52.7542 (1.0) 50.6750 (1.0) 0.8323 (1.51) 50.3874 (1.0) 0.9849 (1.30) 1;1 19.7336 (1.0) 10 1 test_fetch_diagnostics[black-pyrefly] 154.9342 (3.10) 156.7015 (2.97) 156.0514 (3.08) 0.5507 (1.0) 156.2235 (3.10) 0.7576 (1.0) 2;0 6.4081 (0.32) 10 1 test_fetch_diagnostics[black-pyright] 303.7652 (6.07) 310.5299 (5.89) 307.0854 (6.06) 1.7936 (3.26) 306.9718 (6.09) 1.8720 (2.47) 2;0 3.2564 (0.17) 10 1全部项目均值汇总单位ms项目tyPyreflyPyrightty 相对 Pyreflyty 相对 Pyrightblack50.68156.05307.093.08×6.06×discord.py98.39193.76615.501.97×6.26×homeassistant84.92191.181222.582.25×14.40×isort47.74104.59384.702.19×8.06×jinja55.15126.55391.842.29×7.11×pandas359.89543.941902.711.51×5.29×prefect157.44420.961071.262.67×6.80×pytorch52.05134.94683.312.59×13.13×获取诊断场景同样呈现一致的优势ty 在 homeassistant 上仅需 84.92 ms而 Pyright 需要 1,222.58 ms约 14.4×即便在最大的 pandas 项目上ty 也以 359.89 ms 远低于 Pyright 的 1,902.71 ms。值得注意的是该场景中 Pyrefly 与 ty 的差距1.51×–3.08×明显小于 Pyright 与 ty 的差距5.29×–14.40×。两个 LSP 场景的工程含义将两组 LSP 数据放在一起看可以得出一个更完整的结论增量编辑考验的是细粒度增量分析能力——ty 的均值始终低于 60 ms除 pandas 的 57.91 ms 外均在 30 ms 以下达到了可感知的即时反馈水平获取诊断考验的是全量产出诊断的能力——ty 在所有项目上均优于对比工具且随着项目变大如 homeassistant、pandas、pytorch相对 Pyright 的优势反而扩大。这解释了 docs/features/language-server.md 与 README.md 中所述设计目标ty 的 LSP 提供代码导航、补全、代码操作、自动导入、inlay hints、悬停帮助等完整能力对应 语言服务器文档而基准数据表明这些能力建立在足够快的增量与诊断计算之上。若要体验这些能力可参阅 编辑器集成指南支持 VS Code、PyCharm、Neovim 等或直接运行ty server启动语言服务器见 CLI 参考文档。解读基准数据的正确姿势方法与局限官方文档在给出数据的同时也隐含了若干必须注意的解读边界单一硬件平台全部数据来自 macOS Apple M3 Max16 核 / 128 GB。原文档明确提示基准性能可能因操作系统而异并因项目而异因此这些数字不能直接外推到 Windows、Linux 或 x86 平台也不应被视为跨平台的绝对结论。特定版本快照数据对应当前文档记录的版本组合ty 0.0.55 / Pyrefly 1.1.1 / Pyright 1.1.410 / mypy 2.1.0。工具版本迭代后结果会变化ty 当前采用0.0.x版本策略、API 尚不稳定见 README.md 的版本策略说明新旧版本之间可能发生性能与行为变化。无缓存前提README 中用于展示的 CLI 图表明确标注without caching本基准同样反映的是冷启动全量检查性能在开启缓存或增量状态后不同工具的相对表现可能进一步变化。输出中的警告不影响计时Warning: Ignoring non-zero exit code与统计离群值提示如 pandas-stubs 的 mypy均为计时过程中的提示前者源于退出码、后者建议在无干扰的系统上复测二者都不否定计时均值本身。代表性样本9 个项目的选择覆盖了 Web、数据科学、ML 框架、stub 包、配置类库等典型形态但代表真实世界不意味着覆盖所有场景——对于与你自身代码库结构差异较大的项目建议以本仓库数据为参考在目标环境上自行测量。总结BENCHMARKS.md 提供了一份结构完整、方法透明的官方基准在 macOS M3 Max 平台上ty 0.0.55 于全部 9 个测试项目的 CLI 全量检查中均显著快于 Pyrefly、mypy 与 Pyright相对 mypy 最高达 73.86×相对 Pyright 最高达 37.22×在 LSP 场景中ty 的增量编辑均值最低可至 3.78 mspytorch获取诊断相对 Pyright 的优势在大型项目上普遍超过一个数量级。这些数字与 ty 在 README.md 中宣称的设计目标10x–100x 级别提速、面向编辑器的细粒度增量分析相互印证为评估 ty 是否适合引入你的项目无论是 CI 中的全量检查还是编辑器内的交互式体验提供了第一手的量化依据。【免费下载链接】tyAn extremely fast Python type checker and language server, written in Rust.项目地址: https://gitcode.com/GitHub_Trending/ty2/ty创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考