ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Rich 性能基准测试指南:Airspeed Velocity 基准套件的设计、运行与结果发布流程

2026/9/18 15:14:36 拓冰建站 浏览量
Rich 性能基准测试指南:Airspeed Velocity 基准套件的设计、运行与结果发布流程 Rich 性能基准测试指南Airspeed Velocity 基准套件的设计、运行与结果发布流程【免费下载链接】richRich is a Python library for rich text and beautiful formatting in the terminal.项目地址: https://gitcode.com/gh_mirrors/ri/richRich 官方在 benchmarks/ 目录下维护了一套基于 Airspeed Velocityasv的性能基准测试体系用于持续监控各核心渲染路径文本换行、表格、Pretty 输出、颜色降级、Segment 切分等的性能随版本演化的趋势。读完本文你将了解该基准体系如何组织测试套件与测试素材、如何阅读 asv 配置文件 中的每个关键项、如何用asv run/asv publish等命令运行并产出基准结果以及如何按官方流程更新对外的基准仪表盘。基准测试体系概述benchmarks/README.md 开宗明义该目录“contains benchmarks, for monitoring the performance of Rich over time”——即基准测试的首要目标不是给出一个绝对分数而是建立一条可追溯的性能曲线让任何一次重构或优化都能被量化地观察。整套体系由三部分构成基准定义benchmarks/benchmarks.py 中的各测试套件Suite配合 benchmarks/snippets.py 中的测试素材运行环境配置仓库根目录的 asv.conf.json声明 Python 版本、虚拟环境类型、结果与 HTML 输出目录等结果与发布benchmarks/results/下的 JSON 结果文件以及经asv publish生成的静态站点benchmarks/html/与对外仪表盘。README 中还提醒完整命令选项应以asv run --help的输出为准下文只覆盖常用操作。asv 配置文件逐项解读asv.conf.json 是与官方文档 关联配置 中../asv.conf.json相对链接指向的同一文件位于仓库根目录其关键配置项如下配置项值作用version1asv 配置文件格式版本projectrich被基准测试的项目名也用于卸载命令repo.以当前仓库根目录作为 DVCS 仓库根dvcsgit版本控制方式asv 依赖它遍历 commitbranches[master]默认跟踪的分支environment_typevirtualenv为每个 commit 创建隔离的 virtualenv 环境pythons[3.10]固定使用 Python 3.10保证跨 commit 对比口径一致matrix{setuptools: [59.2.0]}矩阵变量锁定 setuptools 版本排除环境差异对结果的干扰install_timeout180项目安装超时 180 秒html_dir./benchmarks/htmlasv publish生成静态站点的输出目录results_dir./benchmarks/resultsJSON 结果文件存放目录env_dir./benchmarks/env各 commit 对应的虚拟环境缓存目录构建与安装链条同样值得关注build_command依次执行pip install poetry、python setup.py build、python -mpip wheel --no-deps --no-index -w {build_cache_dir} {build_dir}先构建 wheel 再安装install_command为in-dir{env_dir} python -mpip install {wheel_file}uninstall_command则用return-codeany容忍卸载失败。这一设计意味着每个被测试的 commit 都是“干净安装”的最新构建产物性能对比排除了陈旧依赖的干扰。基准测试套件设计benchmarks/benchmarks.py 共定义了 8 个测试套件全部输出重定向到StringIO()的Console并统一开启color_systemtruecolor、legacy_windowsFalse以固定渲染路径TextSuitebenchmarks.py#L14-L61针对rich.text.Text的核心操作包括wrap宽 12、overflowfold的窄终端换行、with_indent_guides、fit、split、divide、align、render。每个操作都提供两组输入普通英文素材LOREM_IPSUM与“Unicode 重”素材UNICODE_HEAVY_TEXT含大量日文宽字符、链接与 Markdown 标记见 snippets.py用于验证单元格宽度计算在宽字符、混合文本下的开销。TextHotCacheSuitebenchmarks.py#L64-L72连续 20 次对 Unicode 重文本执行wrap测量缓存命中后的热路径性能与 TextSuite 的冷路径形成对照。SyntaxWrappingSuitebenchmarks.py#L75-L94对Syntax(codesnippets.PYTHON_SNIPPET, lexerpython, word_wrapTrue)分别在宽 20重度换行、60中度换行、100基本不换行三档终端宽度下打印覆盖语法高亮 换行的典型压力场景。TableSuitebenchmarks.py#L97-L126以 “Star Wars Movies” 示例表含 markup 样式单元格分别打印在宽 100无换行与宽 30重度换行的 Console 中。PrettySuitebenchmarks.py#L129-L145对嵌套字典PYTHON_DICT打印默认Pretty、indent_guidesTrue、justifycenter三种形态。StyleSuitebenchmarks.py#L148-L166Style.parse解析 ANSI 名色、hex 色、混合复杂样式dim bold reverse #00ee00 on rgb(123,12,50)以及样式相加style1 style2。ColorSuite 与 ColorSuiteCachedbenchmarks.py#L169-L204将#0d1da0解析出的真彩色分别降级到EIGHT_BIT/STANDARD/WINDOWS三档颜色系统。Cached 版本在setup中先各执行一次降级“预热缓存”专门测量缓存命中路径。SegmentSuitebenchmarks.py#L207-L218对 10 个Segment组成的行调用Segment.divide(line, [5, 10, 20, 50, 108, 110, 118])测量布局系统在按切割点切分渲染行时的开销。测试素材的选取与 Rich 的实际负载高度对应snippets.py 中的PYTHON_SNIPPET是带类型注解与长 docstring 的真实布局算法代码用于 Syntax 换行UNICODE_HEAVY_TEXT是包含日文宽字符、URL、emoji 的 README 式文本用于单元格宽度计算的压力测试MARKUP则是 20 行带粗体/斜体/下划线/链接的 markup 拼接而成用于 render 测试。源码印证基准为何盯住这些热路径结合当前仓库源码可以看出基准套件挑选的正是 Rich 渲染管线中被反复调用的热点颜色降级的缓存Color.downgrade在 rich/color.py#L512-L513 上标注了lru_cache(maxsize1024)降级逻辑会按 HLS 饱和度判断灰度、映射到 256 色立方体。ColorSuite与ColorSuiteCached的成对设计恰好分别度量该函数“未命中/命中 lru_cache”两种状态是典型的缓存收益验证手法。Segment 切分Segment.dividerich/segment.py#L629-L632是 classmethod按cuts位置把 segment 流切分为若干行实现中绑定cached_cell_len做单元格长度计算、用局部变量缓存list.append/clear等方法引用以降低开销。SegmentSuite与TableSuite的“窄终端重度换行”用例正压测这段逻辑。文本 wrap/foldTextSuite中wrap(console, 12, overflowfold)的极窄宽度是最坏情况——几乎每个词都要重新断行能放大cells.py宽度表查询的成本而TextHotCacheSuite的 20 次循环则用于观察这些查找表进入 CPU/函数缓存后的稳态表现。运行基准测试按 benchmarks/README.md 的指引常用操作有三类# 1. 对 master 分支运行基准跟踪 branches 配置中的分支 asv run # 2. 只测当前分支最新一个 commitHEAD^! 表示以 HEAD 为起点的单 commit 历史 asv run HEAD^! # 3. 生成可浏览的静态结果网站HTML 输出到 benchmarks/html asv publish结合 asv.conf.json 的配置可以预期其行为asv run会沿 git 历史逐个 commit 创建benchmarks/env/下的虚拟环境Python 3.10、setuptools 59.2.0构建并安装该 commit 的 wheel 后执行 benchmarks/benchmarks.py 中全部time_*方法耗时较长官方说明“take several minutes”级别且每个 commit 独立计时。查看完整选项建议直接运行asv run --help。结果文件的组织方式asv run的结果落在results_dir即benchmarks/results/当前仓库已收录一台机器的历史数据目录结构如下benchmarks/results/ ├── benchmarks.json # 基准元数据名称、代码哈希、计时类型seconds、版本指纹 └── darrenburns-2022-mbp/ # 以机器名为子目录 ├── machine.json # 机器指纹 └── commit-hash-virtualenv-py3.10[-setuptools59.2.0].json # 每个 commit 一份结果其中 machine.json 记录了采集机指纹Apple M1 Proarm6410 核16GB 内存Darwin 21.2.0这让读者在引用结果时能明确硬件前提。benchmarks.json 则为每个基准项记录type: time、unit: seconds及代码version指纹源码哈希——当基准代码本身变化时asv 会据此区分新旧口径避免把测试改动误读为性能变化。结果文件名的后缀virtualenv-py3.10与-setuptools59.2.0正对应配置文件中的environment_type与matrix体现了“环境指纹进入文件名”的追溯设计。更新基准仪表盘网站的完整流程README 给出了 7 步发布流程这里按原文顺序完整继承并补充说明登记 tag确认要纳入对比的发布 tag 都已写入仓库根目录的 asvhashfile。该文件目前从v10.0.0起逐行列出了后续各版本 tag对 tag 运行基准执行asv run HASHFILE:asvhashfileasv 会读取文件中的每个 tag 作为 commit 起点分别运行耗时数分钟本地生成 HTML执行asv publish产出位于benchmarks/html的静态站点本地预览执行asv preview启动本地 webserver打开其给出的 URL人工检查仪表盘内容是否正常检出 rich-benchmarks 仓库单独检出官方用于托管仪表盘的rich-benchmarks仓库并进入其目录建议与rich检出在同一文件系统层级方便相对拷贝拷贝 HTML把上一步生成的 HTML 复制到该仓库根目录例如cp -r ../rich/benchmarks/html/* .自动发布当这些 HTML 合并进rich-benchmarks的main分支后其 GitHub Action 会自动更新对外仪表盘无需额外部署操作。适用前提与限制基准固定于Python 3.10 setuptools 59.2.0的 virtualenv 环境见 asv.conf.json因此结果反映的是该口径下的相对趋势不宜直接外推到其他解释器版本已有结果文件来自 Apple M1 Pro 单机见 machine.json跨机器对比时需留意 asv 的机器隔离机制asv run HEAD^!适合开发者自测最新 commit但只有跑完全部 tag 并asv publish后才能用于更新公开仪表盘若需扩展基准参照 benchmarks/benchmarks.py 的既有模式即可setup中构造固定Console与素材time_*方法只调用被测 API冷/热路径成对设计素材统一取自 benchmarks/snippets.py。【免费下载链接】richRich is a Python library for rich text and beautiful formatting in the terminal.项目地址: https://gitcode.com/gh_mirrors/ri/rich创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考