Foundry 构建性能优化解析避免 Solidity 源码准备阶段的重复传递性导入遍历【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry本篇技术指南聚焦 Foundry 发布说明中的一个构建性能优化变更——「在准备 Solidity 源码时避免重复的传递性transitive导入遍历从而减少深层依赖图下的构建准备工作量」。文章将结合 变更记录原文 与 crates/cli/src/opts/build/utils.rs 的实际实现说明该优化的背景、源码级原理、涉及的调用链以及实际影响范围。读完本文你将理解 Foundry 在为 Solar 解析器准备源码输入时如何收集依赖、为何旧的逐层遍历在深层依赖图中会产生重复工作以及当前实现如何一次性获取包含传递依赖的完整文件集合。变更记录原文解读本变更以 Foundry 的 changelog fragment 形式存在全文如下--- foundry-cli: patch forge: patch --- Avoid repeated transitive import walks when preparing Solidity sources, reducing build preparation work for deep dependency graphs.这份 fragment 由两部分组成frontmatter 版本契约声明本次变更对foundry-cli与forge两个工作区包各产生一次patch级别的版本号提升。依据 .changelog/README.md 中的规范每个 PR 都需要为受影响的包声明patch、minor或major之一并提供非空的发布说明patch表示向后兼容的修复或性能改进不会破坏既有 API 与命令行行为。发布说明正文一句话点明优化要点——「在准备 Solidity 源码时避免重复的传递性导入遍历减少深层依赖图下的构建准备工作量」。其中两个关键词值得展开一是「准备 Solidity 源码」preparing Solidity sources它指的不是 solc 的编译过程本身而是为相关功能准备待处理的源码文件清单这一前置阶段二是「深层依赖图」deep dependency graphs即import链很长、依赖层层嵌套的项目结构。在开源仓库例如依赖深、文件多的 DeFi 协议代码库中这类结构十分常见因此该优化对真实项目有实际意义。问题背景为何会产生「重复的传递性导入遍历」要理解这个优化需要先了解 Foundry 中多个功能存在的一个共同前置步骤给定用户指定的若干目标源文件或全部项目文件收集其完整依赖闭包——即目标文件本身加上它们直接或间接import的全部 Solidity 文件作为后续分析如 lint、类型分析的输入。从当前仓库源码看这个过程在 crates/cli/src/opts/build/utils.rs 的get_solar_sources_from_compile_output函数中实现。该函数从一次已完成的ProjectCompileOutput中提取 Solar 可兼容的源码集合其核心逻辑为// Collect source path targets let mut source_paths: HashSetPathBuf if let Some(targets) target_paths !targets.is_empty() { let mut source_paths HashSet::new(); for path in targets.iter().filter_map(|path| { is_solidity_file(path).then(|| dunce::canonicalize(path).ok()).flatten() }) { if source_paths.insert(path.clone()) { // imports already includes transitive dependencies. source_paths.extend( output .graph() .imports(path) .into_iter() .filter(|import| !is_ignored(import)) .map(Path::to_path_buf), ); } } source_paths } else { // ... 全部项目文件分支 };这段代码对应 utils.rs 第 197-227 行其中有一行关键注释// imports already includes transitive dependencies.它明确了当前的实现约定对目标文件调用一次graph.imports(path)返回的结果本身已包含全部传递依赖即依赖的依赖因此只需对每个目标文件做一次遍历然后通过HashSet去重合并即可。这正是「避免重复的传递性导入遍历」的落点——如果imports返回的只是直接依赖那么实现就必须对每个新发现的文件再次调用imports逐层展开在依赖图很深时一个公共库文件可能被多层依赖重复命中、被反复遍历多次产生大量冗余工作。可以推断优化前的逻辑很可能采用逐层递归/队列展开的方式每发现一个新文件就重新遍历其导入导致共享依赖尤其是lib/中几乎所有文件都会 import 的公共模块在每一层被重复访问。优化后的实现将「图遍历」的责任收敛到Graph::imports一次调用上用集合去重消除重复。优化实现的核心原理一次性获取传递依赖闭包output.graph().imports(path)返回的是编译产物依赖图中该节点的全部可达导入文件含传递依赖。正因为这一点函数不再需要对外层循环中逐步发现的每个文件重复调用导入查询而是规范化canonicalize每个用户指定的目标文件路径仅当该路径是首次遇到时source_paths.insert(path.clone())返回true才调用一次imports获取其完整传递依赖用is_ignored过滤掉应忽略的路径将剩余部分并入source_paths集合。第 2 步的if source_paths.insert(...)判断起到了两个作用防止重复处理同一目标文件以及利用 HashSet 天然去重合并所有目标及其依赖。整个过程中每个目标文件最多触发一次imports查询依赖文件不再被二次遍历。与「忽略路径」过滤的结合在带目标的路径forge build的 lint 子流程等场景下过滤条件是.into_iter() .filter(|import| !is_ignored(import)) .map(Path::to_path_buf)而is_ignored的实现utils.rs 第 188-194 行会比对调用方传入的ignored_paths在 crates/forge/src/cmd/build.rs 中由config.lint.ignore展开 glob 并规范化得到。过滤发生在合并之前避免了将忽略的依赖路径带入后续处理。无目标路径时的整体收集当未指定目标文件时函数走output.graph().source_files()分支utils.rs 第 218-227 行直接从依赖图中枚举全部源文件并按 Solidity 扩展名过滤。这一分支不涉及逐文件遍历因此不存在「重复的传递性导入遍历」问题——这也侧面印证了优化针对的是带目标文件场景下的收集逻辑。调用链与影响范围该优化位于foundry-cli与forge两个包共同依赖的构建工具链中涉及的主要调用方包括调用位置场景说明crates/forge/src/cmd/build.rs 第 208-209 行forge build内置 lint 流程编译完成后为 Solar lint 收集目标文件及其传递依赖crates/forge/src/cmd/lint.rs 第 143 行forge lint独立命令通过configure_pcx_all_sources配置全部可兼容源码crates/forge/src/multi_runner.rs 第 874 行多运行器multi runner通过configure_pcx_from_compile_output复用编译产物crates/forge/src/mutation/type_analysis.rs 第 75 行变异测试类型分析同上复用编译产物提取 Solar 源码从这些调用点可以看出源码准备逻辑被forge buildlint 子阶段、forge lint、多 runner 并行执行以及变异测试的类型分析等多条路径共享属于「一次优化、多点受益」的公共基础设施层变更。在这些场景中依赖收集的输入往往包含大量文件。以 lint 场景为例build.rs 第 196-206 行input_files由项目路径的input_files_iter()经SkipBuildFilters与忽略 glob 过滤后得到可能包含项目全部 Solidity 文件。若这些文件共享深层依赖逐层重复遍历的成本会随依赖深度和共享度近似二次增长优化后每个目标文件只查询一次深层依赖图下的构建准备工作量显著下降。此外HashSet去重还天然避免了同一文件被多次Source::read读取和重复写入Sources映射utils.rs 第 229-248 行进一步减少了 I/O 与内存占用。验证与实测建议该变更属于构建性能优化不会改变命令行行为或输出格式因此回归验证的重点是功能等价性与性能改善功能等价对一个含深层依赖的项目分别执行forge build --lint或forge lint确认 Solar 报出的 lint 结果与优化前一致——依赖闭包收集结果不应因遍历方式的改变而变化。性能观测在依赖图较深例如嵌套超过 10 层的 import 链、或共享公共库文件的项目上对比优化前后的构建准备耗时。由于本仓库当前提交只保留了优化后的实现可从 utils.rs 的注释 确认现状可直接通过 profile 工具观察get_solar_sources_from_compile_output的执行耗时与imports调用次数。单元测试utils.rs 内置的测试模块第 339-353 行当前主要覆盖 Windows 路径规范化可从源码结构推断若引入新的收集逻辑回归测试重点应断言目标文件 传递依赖的闭包集合与预期一致。从源码结构看该优化与 .changelog/README.md 描述的发布流程一致作为patch级别 fragment它将在下一个版本README 中记录的候选版本的CHANGELOG.md中以「性能改进」类目呈现不涉及任何破坏性变更。总结本次变更解决的是一个具体而典型的工程问题在深层 Solidity 依赖图中重复展开传递导入会带来平方级增长的构建准备工作。通过将依赖闭包的获取收敛为对Graph::imports的单次调用并配合HashSet去重合并Foundry 在准备 Solar 解析输入时避免了重复的传递性导入遍历。该优化沉淀在 crates/cli/src/opts/build/utils.rs 这一公共工具层惠及forge build的 lint 子流程、forge lint、多 runner 与变异测试类型分析等多条调用链以foundry-cli与forge两个包的patch级别变更随版本发布是典型的「小改动、大收益」式构建管道优化。【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/15 15:30:47 · 阅读 1.2k Foundry 构建性能优化解析：避免 Solidity 源码准备阶段的重复传递性导入遍历
Foundry 构建性能优化解析避免 Solidity 源码准备阶段的重复传递性导入遍历【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry本篇技术指南聚焦 Foundry 发布说明中的一个构建性能优化变更——「在准备 Solidity 源码时避免重复的传递性transitive导入遍历从而减少深层依赖图下的构建准备工作量」。文章将结合 变更记录原文 与 crates/cli/src/opts/build/utils.rs 的实际实现说明该优化的背景、源码级原理、涉及的调用链以及实际影响范围。读完本文你将理解 Foundry 在为 Solar 解析器准备源码输入时如何收集依赖、为何旧的逐层遍历在深层依赖图中会产生重复工作以及当前实现如何一次性获取包含传递依赖的完整文件集合。变更记录原文解读本变更以 Foundry 的 changelog fragment 形式存在全文如下--- foundry-cli: patch forge: patch --- Avoid repeated transitive import walks when preparing Solidity sources, reducing build preparation work for deep dependency graphs.这份 fragment 由两部分组成frontmatter 版本契约声明本次变更对foundry-cli与forge两个工作区包各产生一次patch级别的版本号提升。依据 .changelog/README.md 中的规范每个 PR 都需要为受影响的包声明patch、minor或major之一并提供非空的发布说明patch表示向后兼容的修复或性能改进不会破坏既有 API 与命令行行为。发布说明正文一句话点明优化要点——「在准备 Solidity 源码时避免重复的传递性导入遍历减少深层依赖图下的构建准备工作量」。其中两个关键词值得展开一是「准备 Solidity 源码」preparing Solidity sources它指的不是 solc 的编译过程本身而是为相关功能准备待处理的源码文件清单这一前置阶段二是「深层依赖图」deep dependency graphs即import链很长、依赖层层嵌套的项目结构。在开源仓库例如依赖深、文件多的 DeFi 协议代码库中这类结构十分常见因此该优化对真实项目有实际意义。问题背景为何会产生「重复的传递性导入遍历」要理解这个优化需要先了解 Foundry 中多个功能存在的一个共同前置步骤给定用户指定的若干目标源文件或全部项目文件收集其完整依赖闭包——即目标文件本身加上它们直接或间接import的全部 Solidity 文件作为后续分析如 lint、类型分析的输入。从当前仓库源码看这个过程在 crates/cli/src/opts/build/utils.rs 的get_solar_sources_from_compile_output函数中实现。该函数从一次已完成的ProjectCompileOutput中提取 Solar 可兼容的源码集合其核心逻辑为// Collect source path targets let mut source_paths: HashSetPathBuf if let Some(targets) target_paths !targets.is_empty() { let mut source_paths HashSet::new(); for path in targets.iter().filter_map(|path| { is_solidity_file(path).then(|| dunce::canonicalize(path).ok()).flatten() }) { if source_paths.insert(path.clone()) { // imports already includes transitive dependencies. source_paths.extend( output .graph() .imports(path) .into_iter() .filter(|import| !is_ignored(import)) .map(Path::to_path_buf), ); } } source_paths } else { // ... 全部项目文件分支 };这段代码对应 utils.rs 第 197-227 行其中有一行关键注释// imports already includes transitive dependencies.它明确了当前的实现约定对目标文件调用一次graph.imports(path)返回的结果本身已包含全部传递依赖即依赖的依赖因此只需对每个目标文件做一次遍历然后通过HashSet去重合并即可。这正是「避免重复的传递性导入遍历」的落点——如果imports返回的只是直接依赖那么实现就必须对每个新发现的文件再次调用imports逐层展开在依赖图很深时一个公共库文件可能被多层依赖重复命中、被反复遍历多次产生大量冗余工作。可以推断优化前的逻辑很可能采用逐层递归/队列展开的方式每发现一个新文件就重新遍历其导入导致共享依赖尤其是lib/中几乎所有文件都会 import 的公共模块在每一层被重复访问。优化后的实现将「图遍历」的责任收敛到Graph::imports一次调用上用集合去重消除重复。优化实现的核心原理一次性获取传递依赖闭包output.graph().imports(path)返回的是编译产物依赖图中该节点的全部可达导入文件含传递依赖。正因为这一点函数不再需要对外层循环中逐步发现的每个文件重复调用导入查询而是规范化canonicalize每个用户指定的目标文件路径仅当该路径是首次遇到时source_paths.insert(path.clone())返回true才调用一次imports获取其完整传递依赖用is_ignored过滤掉应忽略的路径将剩余部分并入source_paths集合。第 2 步的if source_paths.insert(...)判断起到了两个作用防止重复处理同一目标文件以及利用 HashSet 天然去重合并所有目标及其依赖。整个过程中每个目标文件最多触发一次imports查询依赖文件不再被二次遍历。与「忽略路径」过滤的结合在带目标的路径forge build的 lint 子流程等场景下过滤条件是.into_iter() .filter(|import| !is_ignored(import)) .map(Path::to_path_buf)而is_ignored的实现utils.rs 第 188-194 行会比对调用方传入的ignored_paths在 crates/forge/src/cmd/build.rs 中由config.lint.ignore展开 glob 并规范化得到。过滤发生在合并之前避免了将忽略的依赖路径带入后续处理。无目标路径时的整体收集当未指定目标文件时函数走output.graph().source_files()分支utils.rs 第 218-227 行直接从依赖图中枚举全部源文件并按 Solidity 扩展名过滤。这一分支不涉及逐文件遍历因此不存在「重复的传递性导入遍历」问题——这也侧面印证了优化针对的是带目标文件场景下的收集逻辑。调用链与影响范围该优化位于foundry-cli与forge两个包共同依赖的构建工具链中涉及的主要调用方包括调用位置场景说明crates/forge/src/cmd/build.rs 第 208-209 行forge build内置 lint 流程编译完成后为 Solar lint 收集目标文件及其传递依赖crates/forge/src/cmd/lint.rs 第 143 行forge lint独立命令通过configure_pcx_all_sources配置全部可兼容源码crates/forge/src/multi_runner.rs 第 874 行多运行器multi runner通过configure_pcx_from_compile_output复用编译产物crates/forge/src/mutation/type_analysis.rs 第 75 行变异测试类型分析同上复用编译产物提取 Solar 源码从这些调用点可以看出源码准备逻辑被forge buildlint 子阶段、forge lint、多 runner 并行执行以及变异测试的类型分析等多条路径共享属于「一次优化、多点受益」的公共基础设施层变更。在这些场景中依赖收集的输入往往包含大量文件。以 lint 场景为例build.rs 第 196-206 行input_files由项目路径的input_files_iter()经SkipBuildFilters与忽略 glob 过滤后得到可能包含项目全部 Solidity 文件。若这些文件共享深层依赖逐层重复遍历的成本会随依赖深度和共享度近似二次增长优化后每个目标文件只查询一次深层依赖图下的构建准备工作量显著下降。此外HashSet去重还天然避免了同一文件被多次Source::read读取和重复写入Sources映射utils.rs 第 229-248 行进一步减少了 I/O 与内存占用。验证与实测建议该变更属于构建性能优化不会改变命令行行为或输出格式因此回归验证的重点是功能等价性与性能改善功能等价对一个含深层依赖的项目分别执行forge build --lint或forge lint确认 Solar 报出的 lint 结果与优化前一致——依赖闭包收集结果不应因遍历方式的改变而变化。性能观测在依赖图较深例如嵌套超过 10 层的 import 链、或共享公共库文件的项目上对比优化前后的构建准备耗时。由于本仓库当前提交只保留了优化后的实现可从 utils.rs 的注释 确认现状可直接通过 profile 工具观察get_solar_sources_from_compile_output的执行耗时与imports调用次数。单元测试utils.rs 内置的测试模块第 339-353 行当前主要覆盖 Windows 路径规范化可从源码结构推断若引入新的收集逻辑回归测试重点应断言目标文件 传递依赖的闭包集合与预期一致。从源码结构看该优化与 .changelog/README.md 描述的发布流程一致作为patch级别 fragment它将在下一个版本README 中记录的候选版本的CHANGELOG.md中以「性能改进」类目呈现不涉及任何破坏性变更。总结本次变更解决的是一个具体而典型的工程问题在深层 Solidity 依赖图中重复展开传递导入会带来平方级增长的构建准备工作。通过将依赖闭包的获取收敛为对Graph::imports的单次调用并配合HashSet去重合并Foundry 在准备 Solar 解析输入时避免了重复的传递性导入遍历。该优化沉淀在 crates/cli/src/opts/build/utils.rs 这一公共工具层惠及forge build的 lint 子流程、forge lint、多 runner 与变异测试类型分析等多条调用链以foundry-cli与forge两个包的patch级别变更随版本发布是典型的「小改动、大收益」式构建管道优化。【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考