lld-link 通过 -wl,--stats（linux/macos）或 /link /stats（windows clang-cl）开启各阶段耗时统计，输出符号解析、重定位、文件写入等细分时间，但不包含进程启动、磁盘io、杀软扫描等外部开销；真实瓶颈需结合 measure-command 或 time 测量端到端 wall-clock 时间。
lld-link 怎么开启链接耗时统计
LLD 本身不内置类似 time 的秒级计时报告，但提供了明确的内部计时开关，能直接输出各阶段耗时（符号解析、重定位、写入文件等），这是定位慢链接根源最准的方式。
关键参数是 -Wl,--stats，必须通过编译器前端（如 clang++ 或 clang-cl）透传给 lld-link：
clang++ -fuse-ld=lld -Wl,--stats main.o util.o -o app
输出类似：
== Time summary:
0.021s: Input file reading
0.187s: Symbol table construction
0.094s: Relocation processing
0.032s: Output file writing
0.334s: Total
-
--stats只在 LLD 编译时启用，link.exe或gold不识别该参数 - Windows 下用
clang-cl时，需写成/link /stats（不是-Wl,--stats），否则会被忽略 - 若输出为空或报错
unknown argument: '--stats'，说明你实际没走 LLD（比如clang-cl后没加/linker:lld-link）
为什么 --stats 输出的总时间比 shell time 少
因为 --stats 只统计 LLD 自身工作耗时，不包括：进程启动开销、磁盘读取目标文件（.obj/.o）的时间、符号表从静态库中解压扫描的延迟、以及 Windows 上 PE 头签名/校验的额外步骤。
真实瓶颈常藏在这些“外部”环节：
- 静态库过大（如单个
.lib超 500MB）→ LLD 要遍历所有成员，但--stats把它算进 “Input file reading”，掩盖了内部低效 - 启用了
/DEBUG:FULL（Windows）或-g（Linux）→ 调试段体积暴涨，写入耗时飙升，但--stats的 “Output file writing” 项可能只显示 0.03s，实际磁盘 IO 占了 2s+ - 杀毒软件实时扫描
.exe生成路径 → 这类阻塞完全不出现在 LLD 日志里
怎么对比不同链接器的真实耗时
不能只信 --stats，必须用系统级计时工具测端到端。Windows 推荐用 PowerShell 的 Measure-Command，Linux/macOS 用 time：
# Windows PowerShell（确保 clang-cl 调用的是 lld-link）
Measure-Command { clang-cl /c /O2 main.cpp && lld-link /out:app.exe main.obj /linker:lld-link }
# Linux（注意：g++ 默认不走 lld，必须显式指定） time g++ -fuse-ld=lld -flto=thin main.o -o app
重点看 real 时间（墙钟时间），而不是 user/sys。如果 real 是 1.2s 而 --stats 总和只有 0.4s，那剩下 0.8s 就得查磁盘、杀软、防病毒策略或 AVX 指令兼容性问题（某些旧版 lld-link 在非 AVX CPU 上 fallback 逻辑有延迟）。
链接慢但 --stats 数值正常？检查这几个隐性开关
有些选项看似无关，实则让 LLD 内部流程大幅变长，且不体现在 --stats 分项里：
-
-Wl,--icf=all（标识合并）→ 符号等价性分析是 O(n²) 级别，百万级符号时可能卡住数秒，但日志只记作 “Symbol table construction” 一项 -
-Wl,--lto-O2（LTO 链接优化）→ 实际触发的是 LLVM bitcode 解析+IR 优化流水线，这部分耗时被归入 “Input file reading”，容易误判 -
/DEBUG:FASTLINK（Windows）→ 表面加速，但会强制生成额外调试索引，lld-link 处理时反而更慢；换成/DEBUG:FULL+/PDBALTPATH:可能更快 - 目标文件含大量弱符号（
__attribute__((weak))）→ LLD 对弱符号解析逻辑更保守，尤其在跨模块模板实例化场景下，会反复回溯
真正卡住的时候，往往不是 LLD 本身慢，而是你喂给它的输入结构触发了某个隐藏的二次方算法分支——这时候看 --stats 没用，得结合 procmon（Windows）或 strace -T（Linux）抓系统调用才看得清。
