以Rspack为例，使用Xcode Instruments分析Rust应用性能 点击关注公众号，”技术干货”及时达！序言最近我给 Rspack 提了一个 PR（Pull Request），用于完善 SourceMapDevToolPlugin 的功能和配置选项。你可以在这个链接查看 PR 的具体内容：https://github.com/web-infra-dev/rspack/pull/5108 。 PR 的改动比较大。在完成了新功能并编写了必要的测试用例后，我兴奋地创建了 PR 并期待着评审。评审结果显示功能实现得不错，但考虑到代码的大幅度变更，我被要求进行性能基准测试。测试结果让人有些失望，因为性能显著下降了。 针对性能下降的问题，我投入了三天时间来解决。由于我还是 Rust 领域的新手，对如何进行 Rust 性能分析并不太了解，这个任务较为困难。 经过反复尝试多种方法后，我发现在 Mac 电脑上，用 Instruments 工具做 Rust 应用的 CPU 时间性能分析是最为有效的手段。本文将详细介绍如何利用 Instruments 对 Rust 应用进行 CPU/时间性能分析。 Instruments 的 Time Profiler 工具Instruments 是内嵌于 macOS 的 Xcode 开发环境中的一个强大的分析工具集。它不仅可用于监测内存使用、文件 I/O 和网络活动等领域，还可以帮助开发者深入理解 CPU 性能问题，这对于优化 Rust 程序至关重要。 在 Instruments 的众多工具中，我们将聚焦于 Time Profiler——一个用于揭示程序中 CPU 时间分配的分析器。它唯一的任务是通过采样来揭示 CPU 如何在程序的不同部分之间分配时间，这对开发者意味着能够快速识别性能瓶颈并对症下药。 Time Profiler 基于采样动态记录程序在运行中的堆栈信息，而不是跟踪记录每次函数调用，这允许它在不显著影响程序性能的前提下，提供详尽的性能分析。通过设置适当的采样间隔，如每 1 毫秒采样一次，Instruments 能够搜集到精确的性能数据用于分析。 准备动作为了充分了解 Instruments 的 Time Profiler 工具，我们准备一个运行时长足够以便于采样的示例程序。 下面的代码是一个基于莱布尼茨公式（Leibniz formula for π）的简版 π 值近似计算的 Rust 代码。莱布尼茨公式利用无穷级数来逼近 π 的值，其公式如下： π = 4/1 - 4/3 + 4/5 - 4/7 + 4/9 - 4/11 + ... #[inline(never)] fncalculate_pi(iterations:u64)-f64{ letmutpi:f64=0.0; letmutdenominator:f64=1.0; foriin0..iterations{ ifi%2==0{ pi+=4.0/denominator; }else{ pi-=4.0/denominator; } denominator+=2.0; } pi } fnmain(){ letpi=calculate_pi(1_000_000_000); println!("CalculatedPiis:{}", } 注意，我们在calculate_pi函数前使用#[inline(never)]属性来禁止内联优化，这样能确保在 Instruments 分析结果中清楚地看到这个函数。 接着，我们对Cargo.toml进行配置以生成足够的调试信息，确保在 Instruments 中能够获取人类可读的信息。以下配置可以理解为 Rust 版本的生成源码映射。 [profile.release] debug = 1 # 启用调试信息 strip = false # 不要去除 symbols 最后，通过运行cargo run --release来构建你的 Rust 应用。这里添加--release标志以确保我们正在分析经过 Rust 优化的代码——也就是用户最终将使用的版本。 运行 Time Profiler 分析 Rust 程序运行 Time Profiler 工具只需两个简单的步骤： 第一步，「启动 Time Profiler」: 打开你的终端，导航到你的 Rust 项目目录。使用以下命令，触发性能分析的记录： xcrunxctracerecord--template'TimeProfile'--output./output.trace--launch--/path/to/your/rust/project/target/release/your_binary 这条命令利用xctrace工具采用Time Profiler模板记录性能数据，最终生成一个output.trace文件。请确保替换/path/to/your/rust/project/target/release/your_binary为你的可执行文件的真实路径。 第二步，「查看.trace文件」: 分析记录完毕后，用open命令来打开刚生成的.trace文件，这将自动触发 Instruments 并加载性能数据。 open./output.trace Instruments 启动后你就能直观地看到性能采样结果。例如，在我们的分析中，calculate_pi函数单独耗费了大约 4.90 秒的 CPU 时间，几乎是程序运行时间的全部，占了 99.9%。这种一目了然的数据展示有助于我们迅速锁定可能的性能瓶颈。 解决 Rspack 性能劣化回到我们的 Rspack 项目中，使用 Time Profiler 工具来对 main 分支和开发分支的性能进行对比分析。通过仔观察，我们发现性能下降主要出现在process_assets_stage_dev_tooling方法上。 具体数据如下： main 分支耗时: 1.06 秒开发分支耗时: 2.22 秒 仔细检查调用栈显示，性能下降是由filter_map迭代中的Source.map函数调用引起的。该函数负责为代码生成 source map。 相关代码段如下所示： letassets=compilation .assets() .iter() .filter_map(|(file,asset)|{ letis_match=match&self.test{ Some(test)=test(file.clone()), None=true, ifis_match{ asset.get_source().map(|source|{ letmap_options=MapOptions::new(self.columns); letsource_map=source.map(&map_options); (file,source,source_map) }) }else{ None } }) .collect::Vec 依赖于代码 diff，问题的根源在于我之前将原本利用 Rust 的 rayon 库实现的并发迭代器par_iter更改为了单线程的iter。顾名思义，par_iter用于在多线程中并行处理迭代任务。在实际并未了解 rayon 的情况下，我错误地认为这一更改无关紧要。 实际上，在 main 分支的 Time Profiler 数据中，我们可以清楚地看到source.map方法确实在多个线程上并行执行。 我随后将代码改回使用par_iter，并以此解决了性能问题。性能基准测试随之恢复正常。 最后Rust性能很高么？不，它完全顶不住我的代码。一行代码查了三天，绷不住了。 哈哈，仅是开个玩笑。其实这次深入 Rust 的性能分析我更加理解了一点：要发挥 Rust 的最佳性能，还需要深刻理解它的特性。Rust 确实是一个功能强大的工具，但释放它的全部潜力，同样需要我们的持续学习和实践。 参考资料Rust Profiling with Instruments and FlameGraph on OSX: CPU/Time（https://carol-nichols.com/2015/12/09/rust-profiling-on-osx-cpu-time/）Instruments Help（https://help.apple.com/instruments/mac/10.0/）Rspack Development Guide（https://web-infra-dev.github.io/rspack-dev-guide/profiling/intro.html）点击关注公众号，”技术干货”及时达！ 阅读原文