AI 辅助 Rust 性能优化：让模型分析 criterion 基准测试报告

AI 辅助 Rust 性能优化：让模型分析 criterion 基准测试报告

专栏: AI / AI学习 / Rust性能优化

一、criterion 报告对人类的"不友好"与 AI 的机会

cargo bench 跑完之后，criterion 会在 target/criterion/ 下生成一堆 HTML 报告和 JSON 数据。数据很完整，但问题是：你需要花 10 分钟对着图表、统计数据和火焰图来找到真正的瓶颈。

而 LLM 擅长什么？擅长从结构化数据中提取模式和异常。这正是 criterion 报告和 AI 的完美结合点。

flowchart TB
    subgraph Human["传统流程（人类分析）"]
        H1["cargo bench<br/>运行基准测试"] --> H2["打开 criterion HTML 报告"]
        H2 --> H3["手动对比各版本数据"]
        H3 --> H4["查看火焰图找热点"]
        H4 --> H5["❌ 耗时 15-30 分钟<br/>依赖经验判断"]
    end

    subgraph AI["AI 辅助流程"]
        A1["cargo bench<br/>运行基准测试"] --> A2["提取 JSON 数据 + 火焰图"]
        A2 --> A3["喂给 AI 模型分析"]
        A3 --> A4["AI 输出：<br/>1. 性能回归点<br/>2. 可疑代码路径<br/>3. 优化建议"]
        A4 --> A5["✅ 耗时 2-5 分钟<br/>覆盖可能遗漏的问题"]
    end

    Human -->|"AI 超越人类的地方"| AI

    style H5 fill:#F44336,color:#fff
    style A5 fill:#4CAF50,color:#fff

关键是：怎么把 criterion 的海量数据有效喂给 AI，让它给出真正有价值的分析？

二、提取 criterion 原始数据：从 JSON 到可分析的格式

criterion 在 target/criterion/ 下存储的原始数据是结构化的，但分散在多个文件中。我们需要把它整理成 AI 容易理解的形式。

// 提取 criterion 基准测试数据并格式化为 AI 可分析的 Markdown
use std::fs;
use std::path::Path;

/// criterion 生成的基准测试数据结构（简化版）
#[derive(serde::Deserialize)]
struct CriterionBenchmark {
    /// 基准测试名称，如 "json_parse_large_file"
    full_id: String,
    /// 平均执行时间（纳秒）
    mean_estimate: f64,
    /// 标准差
    std_dev_estimate: f64,
    /// 中位数
    median_estimate: f64,
    /// 最小/最大执行时间
    min_estimate: f64,
    max_estimate: f64,
}

/// 将 criterion 报告转换为 AI 友好的分析格式
fn format_for_ai_analysis(benchmarks: &[CriterionBenchmark]) -> String {
    let mut report = String::from(
        "# Rust Performance Benchmark Report\n\n",
    );

    // 按执行时间降序排列 — 最慢的放最前面，AI 能更快定位瓶颈
    let mut sorted: Vec<_> = benchmarks.iter().collect();
    sorted.sort_by(|a, b| b.mean_estimate.partial_cmp(&a.mean_estimate).unwrap());

    report.push_str("## Top Slowest Benchmarks\n\n");
    report.push_str("| Benchmark | Mean (ns) | Median (ns) | Std Dev (ns) | Min | Max |\n");
    report.push_str("|-----------|-----------|-------------|-------------|-----|-----|\n");

    for bench in sorted.iter().take(20) {
        // 只用前 20 个最慢的 benchmark 避免 token 超限
        report.push_str(&format!(
            "| {} | {:.1} | {:.1} | {:.1} | {:.1} | {:.1} |\n",
            bench.full_id,
            bench.mean_estimate,
            bench.median_estimate,
            bench.std_dev_estimate,
            bench.min_estimate,
            bench.max_estimate
        ));
    }

    report.push_str("\n## Analysis Prompt\n\n");
    report.push_str(
        "请分析以上 Rust 基准测试数据，关注以下方面：\n",
    );
    report.push_str(
        "1. 执行时间最长的 benchmark 是否是预期的热点？\n",
    );
    report.push_str(
        "2. 标准差 > 平均值 10% 的 benchmark 是否存在不稳定因素？\n",
    );
    report.push_str(
        "3. 根据 benchmark 名称推测可能的优化方向。\n",
    );

    report
}

这一步的关键是做数据预处理——不要直接把整个 criterion 目录扔给 AI。你必须挑出最关键的数据，用表格和明确的 prompt 组织起来。垃圾进，垃圾出；好数据进，好分析出。

三、用 AI 做"性能回归检测"：发现人眼容易忽略的变化

criterion 自带回归检测功能，但它只能告诉你"变慢了"，不能告诉你为什么变慢。这是 AI 的强项。

/// 比较两个版本的 benchmark 结果，检测性能回归
fn detect_regression(
    old_benchmarks: &[CriterionBenchmark],
    new_benchmarks: &[CriterionBenchmark],
) -> String {
    let mut report = String::from("# Performance Regression Report\n\n");

    // 建立版本对比关系
    let old_map: std::collections::HashMap<&str, f64> = old_benchmarks
        .iter()
        .map(|b| (b.full_id.as_str(), b.mean_estimate))
        .collect();

    let mut regressions: Vec<(String, f64)> = Vec::new();

    for bench in new_benchmarks {
        if let Some(&old_time) = old_map.get(bench.full_id.as_str()) {
            // 计算性能变化百分比（正数 = 变慢了）
            let change_pct = ((bench.mean_estimate - old_time) / old_time) * 100.0;

            // 设置 5% 的回归阈值 — 小于这个值的波动可能是噪音
            if change_pct > 5.0 {
                regressions.push((bench.full_id.clone(), change_pct));
            }
        }
    }

    // 按回归程度降序排列
    regressions.sort_by(|a, b| b.1.partial_cmp(&a.1).unwrap());

    if regressions.is_empty() {
        report.push_str("✅ 未检测到显著性能回归 (>5%)。\n");
    } else {
        report.push_str("⚠️ 检测到以下性能回归：\n\n");
        for (name, pct) in &regressions {
            report.push_str(&format!(
                "- **{}**: 性能下降 **{:.1}%**（需要排查原因）\n", name, pct
            ));
        }
        report.push_str("\n请 AI 分析：这些回归是否与最近的代码变更相关？\n");
        report.push_str("最近修改的文件列表和 diff 如下：\n");
        // 这里追加 git diff 内容
    }

    report
}

实际使用时的 pipeline 是：跑 benchmark → 提取数据 → 结合 git diff → 喂给 AI → 得到分析。这个流程可以在 CI 里自动化，每次 PR 自动生成性能回归报告。

生产实战经验：AI 误报回归的两个原因

我用 AI 做性能回归检测时踩过一个坑：AI 模型有时候会把 benchmark 的正常波动误判为性能回归。criterion 的 benchmark 本身就有方差（尤其是那些涉及内存分配或系统调用的），如果某次 CI run 时宿主机负载高，benchmark 时间会波动 10-20%。AI 看到这个变化会报告"性能下降 15%"，但实际上只是噪音。

解决办法是设置一个合理的回归阈值，并且做多次采样确认。我在 detect_regression 函数里加了一个"连续两次 regression 才报警"的逻辑：

/// 改进版的回归检测：需要连续两次 benchmark 都显示回归才报警
fn detect_regression_strict(
    old: &[CriterionBenchmark],
    new1: &[CriterionBenchmark], // 第一次新跑的结果
    new2: &[CriterionBenchmark], // 第二次确认
    threshold: f64,
) -> Vec<(String, f64)> {
    let mut confirmed = Vec::new();
    for bench in new1 {
        if let (Some(old_t), Some(new2_t)) = (
            old.iter().find(|b| b.full_id == bench.full_id).map(|b| b.mean_estimate),
            new2.iter().find(|b| b.full_id == bench.full_id).map(|b| b.mean_estimate),
        ) {
            let change1 = (bench.mean_estimate - old_t) / old_t * 100.0;
            let change2 = (new2_t - old_t) / old_t * 100.0;
            // 两次都超过阈值才报回归
            if change1 > threshold && change2 > threshold {
                confirmed.push((bench.full_id.clone(), (change1 + change2) / 2.0));
            }
        }
    }
    confirmed
}

另一个坑是 LLM 的 context window 限制。criterion 在大项目里会生成几十个 benchmark 的数据，JSON 报告可能超过 10KB。如果直接把原始 JSON 喂给 AI，可能会超出 token 限制。我现在在 format_for_ai_analysis 里只取前 20 个最慢的 benchmark，把输入控制在 3000 token 以内。

四、从 AI 分析到可落地的优化

AI 分析出问题后，真正的价值在于把建议转化为具体的代码优化。这里分享一个我实际经历的案例：

AI 分析我的 JSON 解析 benchmark 时发现：

1. parse_string_value 函数占用了 68% 的执行时间
2. 主要热点是字符串分配：每次解析到字符串值都要调用 String::with_capacity()
3. 建议：使用 Cow<'_, str> 来减少不必要的字符串拷贝

use std::borrow::Cow;

/// AI 建议优化前的代码 — 每次解析都分配新 String
fn parse_string_old(input: &str) -> String {
    // 找到引号包围的字符串内容
    let start = input.find('"').unwrap() + 1;
    let end = input[start..].find('"').unwrap();
    // ⚠️ AI 指出的性能问题：这里每次都要堆分配
    input[start..start + end].to_string()
}

/// AI 建议优化后的代码 — 用 Cow 延迟分配
fn parse_string_new<'a>(input: &'a str) -> Cow<'a, str> {
    let start = input.find('"').unwrap() + 1;
    let end = input[start..].find('"').unwrap();
    let raw = &input[start..start + end];

    // 如果字符串不包含转义字符，直接返回引用（零拷贝）
    if !raw.contains('\\') {
        Cow::Borrowed(raw)
    } else {
        // 只有需要处理转义时才分配新字符串
        Cow::Owned(unescape(raw))
    }
}

/// 处理转义字符（仅在需要时调用）
fn unescape(s: &str) -> String {
    s.replace("\\n", "\n")
     .replace("\\t", "\t")
     .replace("\\\"", "\"")
}

优化后的 benchmark 数据显示，parse_string 的执行时间从 320ns 降到了 95ns——提升了 3.3 倍。这个优化思路来自 AI，但最终的实现需要开发者的判断力。

实战案例：AI 给的优化建议不都是对的

上面那个 Cow<str> 的优化看起来很美好，但我在实际项目中遇到过一个反例：当字符串很短（小于 20 字节）时，Cow::Owned 的堆分配开销反而比直接返回 String 更大，因为 Cow 本身的 enum 有两个指针大小的开销，而且分支判断（if !raw.contains('\\')）在字符串很短时反而是主要开销。

// 基准测试：短字符串场景下 Cow vs 直接返回 String
fn bench_cow_short(c: &mut Criterion) {
    c.bench_function("cow_short", |b| {
        b.iter(|| parse_string_new("\"hi\""))
    });
    c.bench_function("string_short", |b| {
        b.iter(|| parse_string_old("\"hi\""))
    });
}

// 结果（纳秒）：
// cow_short:    52ns
// string_short: 38ns  ← 直接返回 String 更快

另一个 AI 给的错误建议是"用 array 代替 Vec 来提升性能"。AI 的理由是"栈上分配比堆上快"。但实际上，当数组大小超过 1024 字节时，栈上分配会导致栈溢出（stack overflow），而且会把函数调用的栈帧撑得很大，反而降低 CPU 缓存命中率。正确的建议应该是"如果大小在编译期确定且小于 1024 字节，用 array；否则用 Vec 并在 hot path 外预分配"。

教训：AI 给的优化建议一定要用 criterion 验证，不要盲目应用。AI 不知道你的实际数据分布，它给的是"理论上"的优化，但理论不等于实际。我现在的工作流程是：AI 给建议 → 写 benchmark → 跑 criterion → 只看数字做决定。AI 是顾问，不是决策者。

五、总结

AI 辅助性能分析不是让 AI 替你写代码，而是让 AI 替你阅读数据。criterion 的报告对人眼是噪音，对 AI 是信号。

三个关键实践原则：

1. 不要直接给 AI 原始报告文件——先提取关键数据，用表格和 prompt 组织好。
2. 结合 git diff 做回归检测——AI 能把代码变更和性能变化关联起来，这是人类最难做的事。
3. AI 的建议是起点，不是终点——它可能提出一个不合理的优化方向，也可能提出一个你没想到的零拷贝技巧。最终判断权在你自己。

把 AI 当作你的"性能分析 copilot"，它的价值不是替代你的思考，而是放大你的分析效率。