axiom-build-performance by charleswiltgen/axiom
npx skills add https://github.com/charleswiltgen/axiom --skill axiom-build-performance系统化的 Xcode 构建性能分析与优化。核心原则:先测量后优化,优先优化关键路径。
要进行自动扫描和快速修复:
/axiom:optimize-build
构建优化代理会扫描常见问题并提供即时修复。使用此技能进行深度分析。
原因:无法改进未测量的内容。基准可以防止安慰剂式优化。
# 清理构建(消除所有缓存)
xcodebuild clean build -scheme YourScheme
# 测量时间
time xcodebuild build -scheme YourScheme
# 或使用 Xcode UI
Product → Perform Action → Build with Timing Summary
记录:
示例基准:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
Clean build: 247 seconds
Incremental (1 file change): 12 seconds
Longest phase: Compile Swift sources (189s)
访问方式:
需要关注的内容:
关键路径 是拥有无限 CPU 核心时的最短可能构建时间。它由最长的依赖任务链定义。
┌─────────────────────────────────────────┐
│ Critical Path: A → B → C → D (120s) │
│ │
│ Task A: 30s ─────────┐ │
│ Task B: 40s ├─→ D: 20s │
│ Task C: 30s ─────────┘ │
│ │
│ Even with 100 CPUs, build takes 120s │
└─────────────────────────────────────────┘
目标:通过打破依赖关系来缩短关键路径。
垂直空白区域:等待输入的任务
Timeline:
████████░░░░░░░░████████ ← 差:空闲核心在等待
████████████████████████ ← 好:持续工作
长的水平条:缓慢的单个任务
Task A: ████████████████████ (45 seconds) ← 需要调查
Task B: ███ (3 seconds) ← 良好
串行目标构建:目标不必要地等待
Framework: ████████░░░░░░░░░░ ← 等待中
App: ░░░░░░░░░░████████ ← 被延迟
Better (parallel):
Framework: ████████
App: ░░░░████████████
编译是最慢的阶段吗? ├─ 是 → 检查类型检查性能(步骤 4) └─ 否 → 链接慢吗? ├─ 是 → 检查链接依赖项(步骤 5) └─ 否 → 脚本慢吗? ├─ 是 → 优化构建阶段脚本(步骤 6) └─ 否 → 检查并行化(步骤 7)
症状:"Compile Swift sources" 耗时超过构建时间的 50%。
诊断:
启用编译器警告以查找缓慢的函数:
// 添加到 Debug 构建设置 → Other Swift Flags
-warn-long-function-bodies 100
-warn-long-expression-type-checking 100
构建 → Xcode 显示警告:
MyView.swift:42: Function body took 247ms to type-check (limit: 100ms)
LoginViewModel.swift:18: Expression took 156ms to type-check (limit: 100ms)
修复缓慢的类型检查:
// ❌ 慢 - 复杂的类型推断 (247ms)
func calculateTotal(items: [Item]) -> Double {
return items
.filter { $0.isActive }
.map { $0.price * $0.quantity }
.reduce(0, +)
}
// ✅ 快 - 显式类型 (12ms)
func calculateTotal(items: [Item]) -> Double {
let activeItems: [Item] = items.filter { $0.isActive }
let prices: [Double] = activeItems.map { $0.price * $0.quantity }
let total: Double = prices.reduce(0, +)
return total
}
常见的缓慢模式:
预期影响:受影响文件的编译速度提高 10-30%。
症状:构建时间线显示 Debug 构建中有长的脚本阶段。
常见原因:
修复:使脚本有条件执行
# ❌ 差 - 在 ALL 配置中运行(为调试构建增加 6+ 秒)
#!/bin/bash
firebase crashlytics upload-symbols
# ✅ 好 - 在 Debug 中跳过
#!/bin/bash
if [ "${CONFIGURATION}" = "Release" ]; then
firebase crashlytics upload-symbols
fi
# 示例节省:每次增量调试构建节省 6.3 秒
脚本阶段沙盒化 (Xcode 14+)
启用以防止数据竞争并改进并行化:
Build Settings → User Script Sandboxing → YES
原因:强制您显式声明输入/输出,从而实现并行执行。
# 具有正确输入/输出的脚本阶段
Input Files:
$(SRCROOT)/input.txt
$(DERIVED_FILE_DIR)/checksum.txt
Output Files:
$(DERIVED_FILE_DIR)/output.html
# 现在 Xcode 知道依赖关系,可以安全地并行化
并行脚本执行:
Build Settings → FUSE_BUILD_SCRIPT_PHASES → YES
⚠️ 警告:仅当所有脚本都声明了正确的输入/输出时才启用。否则会出现数据竞争。
预期影响:每次增量调试构建节省 5-10 秒。
症状:增量构建重新编译整个模块。
检查当前设置:
# 在 project.pbxproj 中
grep "SWIFT_COMPILATION_MODE" project.pbxproj
最优配置:
| 配置 | 设置 | 原因 |
|---|---|---|
| Debug | singlefile (增量) | 仅重新编译更改的文件 |
| Release | wholemodule | 最大优化 |
// ❌ 差 - Debug 中使用 Whole Module
SWIFT_COMPILATION_MODE = wholemodule; // ALL configs
// ✅ 好 - Debug 中使用增量
Debug: SWIFT_COMPILATION_MODE = singlefile;
Release: SWIFT_COMPILATION_MODE = wholemodule;
如何修复:
预期影响:增量调试构建速度提高 40-60%。
症状:Debug 构建为多个架构(x86_64 + arm64)编译。
检查:
grep "ONLY_ACTIVE_ARCH" project.pbxproj
修复:
| 配置 | 设置 | 原因 |
|---|---|---|
| Debug | YES | 仅构建当前设备的架构(arm64 或 x86_64) |
| Release | NO | 构建通用二进制文件 |
如何修复:
预期影响:调试构建速度提高 40-50%(架构数量减半)。
症状:Debug 构建不必要地生成 dSYM。
最优配置:
| 配置 | 设置 | 原因 |
|---|---|---|
| Debug | dwarf | 嵌入式调试信息,更快 |
| Release | dwarf-with-dsym | 用于崩溃报告的独立 dSYM |
# 检查当前设置
grep "DEBUG_INFORMATION_FORMAT" project.pbxproj
如何修复:
预期影响:每次调试构建节省 3-5 秒。
症状:构建时间线显示目标可以并行构建时却串行构建。
检查方案配置:
依赖图示例:
App ──┬──→ Framework A
└──→ Framework B
Framework A ──→ Utilities
Framework B ──→ Utilities
时间线(差 - 串行):
Utilities: ████████░░░░░░░░░░░░░░
Framework A: ░░░░░░░░████████░░░░░░
Framework B: ░░░░░░░░░░░░░░░░████████
App: ░░░░░░░░░░░░░░░░░░░░░░████
时间线(好 - 并行):
Utilities: ████████
Framework A: ░░░░░░░░████████
Framework B: ░░░░░░░░████████
App: ░░░░░░░░░░░░░░░░████
预期影响:与独立目标数量成比例(例如,2 个并行目标 ≈ 2 倍速度提升)。
是什么:Swift 模块与编译分开生成,从而更快地解除下游目标的阻塞。
之前(Xcode 13):
Framework: Compile ████████████ → Emit Module █
App: ░░░░░░░░░░░░░░░░░░░░░░░░░█████████
↑
等待 Framework 编译完成
之后(Xcode 14+):
Framework: Compile ████████████
Emit Module ███
App: ░░░░░░███████████
↑
模块一发射就开始
自动:无需配置,在 Xcode 14+ 和 Swift 5.7+ 中自动工作。
预期影响:多目标构建中的空闲时间减少 20-40%。
是什么:如果模块已准备就绪,链接可以在所有编译完成之前开始。
影响:进一步减少依赖链中的关键路径。
自动:在 Xcode 14+ 中自动工作。
是什么:Xcode 26 引入了编译缓存,可以在清理构建之间重用先前编译的工件。
构建设置:
Build Settings → COMPILATION_CACHE_ENABLE_CACHING → YES
工作原理:
xcodebuild clean 之后,也可以重用缓存的工件何时启用:
验证:
# 启用缓存进行构建
xcodebuild build -scheme YourScheme \
COMPILATION_CACHE_ENABLE_CACHING=YES
# 检查构建日志中的缓存信息
当前限制 (Xcode 26):
预期影响:初始缓存填充后,清理构建速度提高 20-40%(对于有利的项目可达 70%+)。
是什么:Xcode 将模块编译拆分为显式构建任务,而不是隐式的按需编译。在 Xcode 26 中默认对 Swift 启用。
隐式模块的问题(Xcode 16 之前):
当编译器遇到导入时,它会按需构建模块:
Compile A.swift ─── needs UIKit ───→ (builds UIKit.pcm) ───→ continues
Compile B.swift ─── needs UIKit ───→ (waits for A to finish) ───→ uses cached
Compile C.swift ─── needs UIKit ───→ (waits) ───→ uses cached
问题:
显式构建模块解决方案:
Xcode 现在将编译分为三个阶段:
Phase 1: SCAN Phase 2: BUILD MODULES Phase 3: COMPILE
┌──────────────────┐ ┌──────────────────────┐ ┌──────────────────┐
│ Scan A.swift │ │ Build UIKit.pcm │ │ Compile A.swift │
│ Scan B.swift │ → │ Build Foundation.pcm │ → │ Compile B.swift │
│ Scan C.swift │ │ Build SwiftUI.pcm │ │ Compile C.swift │
└──────────────────┘ └──────────────────────┘ └──────────────────┘
(fast) (parallel) (parallel)
好处:
启用/禁用(如果需要):
Build Settings → Explicitly Built Modules → YES (Xcode 26 中 Swift 的默认值)
模块变体 (WWDC 2024-10171)
同一个模块可能会用不同的设置构建多次:
Build Log:
Compile Clang module 'UIKit' (hash: abc123) ← 变体 1
Compile Clang module 'UIKit' (hash: def456) ← 变体 2
Compile Swift module 'UIKit' (hash: ghi789) ← 变体 3
变体的常见原因:
诊断变体:
Product → Perform Action → Build with Timing Summary减少变体(在项目/工作区级别统一设置):
# 检查宏差异
grep "GCC_PREPROCESSOR_DEFINITIONS" project.pbxproj
# 将特定于目标的宏尽可能移动到项目级别
Project → Build Settings → Preprocessor Macros → [在此处统一]
示例 (来自 WWDC 2024-10171):
Before: 4 UIKit variants (2 Swift × 2 Clang)
After: 2 UIKit variants (unified settings)
Impact: Fewer module builds = faster incremental builds
预期影响:通过减少重复模块编译,构建速度提高 10-30%。
注意:Swift Build (Xcode 26+):Xcode 现在使用 Swift Build,这是 Apple 的开源构建引擎。这提供了更可预测的构建、更好的 SPM 集成以及跨平台支持(Linux、Windows、Android)。无需配置。
必需步骤:
基准(更改前):
xcodebuild clean build -scheme YourScheme 2>&1 | tee baseline.log
一次应用一个优化
测量改进:
xcodebuild clean build -scheme YourScheme 2>&1 | tee optimized.log
比较:
# 从日志中提取构建时间
grep "Build succeeded" baseline.log
grep "Build succeeded" optimized.log
示例:
Baseline: Build succeeded (247.3 seconds)
Optimized: Build succeeded (156.8 seconds)
Improvement: 90.5 seconds (36.6% faster)
优化前:
优化后:
关键路径:应该明显缩短。
基准:
应用的优化:
结果:
基准:
应用的优化:
结果:
错误:"我认为这会有帮助" → 进行更改 → 不测量。
为什么不好:安慰剂式改进,浪费时间,实际回归未被注意。
修复:始终先测量 → 更改一件事 → 再测量。
错误:将 Release 设置为增量编译以获得"更快的构建"。
为什么不好:Release 构建应针对运行时性能进行优化,而不是构建速度。您向用户发布的是 Release 构建。
修复:仅优化 Debug 构建的速度。保持 Release 针对运行时进行优化。
错误:移除合法的依赖关系以"使构建并行"。
为什么不好:构建错误、未定义行为、竞争条件。
修复:仅并行化真正独立的目标。使用构建时间线来识别安全的机会。
错误:启用并行脚本但不声明输入/输出。
为什么不好:数据竞争、非确定性的构建失败、不正确的构建。
修复:首先启用 ENABLE_USER_SCRIPT_SANDBOXING = YES,修复所有错误,然后启用 FUSE_BUILD_SCRIPT_PHASES。
检查:
xcodebuild clean)检查:
检查:
-warn-long-function-bodies 100 (带连字符)# 查找编译最慢的文件
xcodebuild -workspace YourApp.xcworkspace \
-scheme YourScheme \
clean build \
OTHER_SWIFT_FLAGS="-Xfrontend -debug-time-function-bodies" 2>&1 | \
grep ".[0-9]ms" | \
sort -nr | \
head -20
输出:
247.3ms MyViewModel.swift:42:1 func calculateTotal
156.8ms LoginView.swift:18:3 var body
89.2ms NetworkManager.swift:67:1 func handleResponse
...
操作:为最慢的函数添加显式类型。
# 从构建日志中
Build target 'MyApp' (project 'MyApp')
Compile Swift source files (128.4 seconds)
Link MyApp (12.3 seconds)
Run custom shell script (6.7 seconds)
操作:首先优化最长的阶段。
在认为构建已优化之前:
测量
编译设置
并行化
Xcode 26+(如果适用)
COMPILATION_CACHE_ENABLE_CACHING)WWDC:2018-408, 2022-110364, 2024-10171, 2025-247
文档:/xcode/improving-the-speed-of-incremental-builds, /xcode/building-your-project-with-explicit-module-dependencies
工具:Xcode Build Timeline (Xcode 14+), Build with Timing Summary (Product → Perform Action), Modules Report (Xcode 16+), Instruments Time Profiler
记住:构建性能优化是关于系统化测量和针对性改进。首先优化关键路径,测量所有内容,并在构建时间线中验证改进。
每周安装次数
133
代码仓库
GitHub 星标数
681
首次出现
2026年1月21日
安全审计
安装于
opencode117
codex112
gemini-cli110
cursor109
claude-code108
github-copilot107
Systematic Xcode build performance analysis and optimization. Core principle : Measure before optimizing, then optimize the critical path first.
For automated scanning and quick wins:
/axiom:optimize-build
The build-optimizer agent scans for common issues and provides immediate fixes. Use this skill for deep analysis.
Why : You can't improve what you don't measure. Baseline prevents placebo optimizations.
# Clean build (eliminates all caching)
xcodebuild clean build -scheme YourScheme
# Measure time
time xcodebuild build -scheme YourScheme
# Or use Xcode UI
Product → Perform Action → Build with Timing Summary
Record :
Example baseline :
Clean build: 247 seconds
Incremental (1 file change): 12 seconds
Longest phase: Compile Swift sources (189s)
Access :
What to look for :
The critical path is the shortest possible build time with unlimited CPU cores. It's defined by the longest chain of dependent tasks.
┌─────────────────────────────────────────┐
│ Critical Path: A → B → C → D (120s) │
│ │
│ Task A: 30s ─────────┐ │
│ Task B: 40s ├─→ D: 20s │
│ Task C: 30s ─────────┘ │
│ │
│ Even with 100 CPUs, build takes 120s │
└─────────────────────────────────────────┘
Goal : Shorten the critical path by breaking dependencies.
Empty vertical space : Tasks waiting for inputs
Timeline:
████████░░░░░░░░████████ ← Bad: idle cores waiting
████████████████████████ ← Good: continuous work
Long horizontal bars : Slow individual tasks
Task A: ████████████████████ (45 seconds) ← Investigate
Task B: ███ (3 seconds) ← Fine
Serial target builds : Targets waiting unnecessarily
Framework: ████████░░░░░░░░░░ ← Waiting
App: ░░░░░░░░░░████████ ← Delayed
Better (parallel):
Framework: ████████
App: ░░░░████████████
Is compilation the slowest phase? ├─ YES → Check type checking performance (Step 4) └─ NO → Is linking slow? ├─ YES → Check link dependencies (Step 5) └─ NO → Are scripts slow? ├─ YES → Optimize build phase scripts (Step 6) └─ NO → Check parallelization (Step 7)
Symptom : "Compile Swift sources" takes >50% of build time.
Diagnosis :
Enable compiler warnings to find slow functions:
// Add to Debug build settings → Other Swift Flags
-warn-long-function-bodies 100
-warn-long-expression-type-checking 100
Build → Xcode shows warnings:
MyView.swift:42: Function body took 247ms to type-check (limit: 100ms)
LoginViewModel.swift:18: Expression took 156ms to type-check (limit: 100ms)
Fix slow type checking :
// ❌ SLOW - Complex type inference (247ms)
func calculateTotal(items: [Item]) -> Double {
return items
.filter { $0.isActive }
.map { $0.price * $0.quantity }
.reduce(0, +)
}
// ✅ FAST - Explicit types (12ms)
func calculateTotal(items: [Item]) -> Double {
let activeItems: [Item] = items.filter { $0.isActive }
let prices: [Double] = activeItems.map { $0.price * $0.quantity }
let total: Double = prices.reduce(0, +)
return total
}
Common slow patterns :
Expected impact : 10-30% faster compilation for affected files.
Symptom : Build Timeline shows long script phases in Debug builds.
Common culprits :
Fix : Make scripts conditional
# ❌ BAD - Runs in ALL configurations (adds 6+ seconds to debug builds)
#!/bin/bash
firebase crashlytics upload-symbols
# ✅ GOOD - Skip in Debug
#!/bin/bash
if [ "${CONFIGURATION}" = "Release" ]; then
firebase crashlytics upload-symbols
fi
# Example savings: 6.3 seconds per incremental debug build
Script Phase Sandboxing (Xcode 14+)
Enable to prevent data races and improve parallelization:
Build Settings → User Script Sandboxing → YES
Why : Forces you to declare inputs/outputs explicitly, enabling parallel execution.
# Script phase with proper inputs/outputs
Input Files:
$(SRCROOT)/input.txt
$(DERIVED_FILE_DIR)/checksum.txt
Output Files:
$(DERIVED_FILE_DIR)/output.html
# Now Xcode knows dependencies and can parallelize safely
Parallel Script Execution :
Build Settings → FUSE_BUILD_SCRIPT_PHASES → YES
⚠️ WARNING : Only enable if ALL scripts have correct inputs/outputs declared. Otherwise you'll get data races.
Expected impact : 5-10 seconds saved per incremental debug build.
Symptom : Incremental builds recompile entire modules.
Check current settings :
# In project.pbxproj
grep "SWIFT_COMPILATION_MODE" project.pbxproj
Optimal configuration :
| Configuration | Setting | Why |
|---|---|---|
| Debug | singlefile (Incremental) | Only recompiles changed files |
| Release | wholemodule | Maximum optimization |
// ❌ BAD - Whole module in Debug
SWIFT_COMPILATION_MODE = wholemodule; // ALL configs
// ✅ GOOD - Incremental for Debug
Debug: SWIFT_COMPILATION_MODE = singlefile;
Release: SWIFT_COMPILATION_MODE = wholemodule;
How to fix :
Expected impact : 40-60% faster incremental debug builds.
Symptom : Debug builds compile for multiple architectures (x86_64 + arm64).
Check :
grep "ONLY_ACTIVE_ARCH" project.pbxproj
Fix :
| Configuration | Setting | Why |
|---|---|---|
| Debug | YES | Only build for current device (arm64 OR x86_64) |
| Release | NO | Build universal binary |
How to fix :
Expected impact : 40-50% faster debug builds (half the architectures).
Symptom : Debug builds generating dSYMs unnecessarily.
Optimal configuration :
| Configuration | Setting | Why |
|---|---|---|
| Debug | dwarf | Embedded debug info, faster |
| Release | dwarf-with-dsym | Separate dSYM for crash reporting |
# Check current
grep "DEBUG_INFORMATION_FORMAT" project.pbxproj
How to fix :
Expected impact : 3-5 seconds saved per debug build.
Symptom : Build Timeline shows targets building sequentially when they could be parallel.
Check scheme configuration :
Dependency graph example :
App ──┬──→ Framework A
└──→ Framework B
Framework A ──→ Utilities
Framework B ──→ Utilities
Timeline (bad - serial) :
Utilities: ████████░░░░░░░░░░░░░░
Framework A: ░░░░░░░░████████░░░░░░
Framework B: ░░░░░░░░░░░░░░░░████████
App: ░░░░░░░░░░░░░░░░░░░░░░████
Timeline (good - parallel) :
Utilities: ████████
Framework A: ░░░░░░░░████████
Framework B: ░░░░░░░░████████
App: ░░░░░░░░░░░░░░░░████
Expected impact : Proportional to number of independent targets (e.g., 2 parallel targets = ~2x faster).
What it is : Swift modules are produced separately from compilation, unblocking downstream targets faster.
Before (Xcode 13) :
Framework: Compile ████████████ → Emit Module █
App: ░░░░░░░░░░░░░░░░░░░░░░░░░█████████
↑
Waiting for Framework compilation to finish
After (Xcode 14+) :
Framework: Compile ████████████
Emit Module ███
App: ░░░░░░███████████
↑
Starts as soon as module emitted
Automatic : No configuration needed, works in Xcode 14+ with Swift 5.7+.
Expected impact : Reduces idle time in multi-target builds by 20-40%.
What it is : Linking can start before all compilation finishes if the module is ready.
Impact : Further reduces critical path in dependency chains.
Automatic : Works in Xcode 14+ automatically.
What it is : Xcode 26 introduces compilation caching that reuses previously compiled artifacts across clean builds.
Build Settings :
Build Settings → COMPILATION_CACHE_ENABLE_CACHING → YES
How it works :
xcodebuild clean, cached artifacts can be reusedWhen to enable :
Verification :
# Build with caching enabled
xcodebuild build -scheme YourScheme \
COMPILATION_CACHE_ENABLE_CACHING=YES
# Check build log for cache information
Current limitations (Xcode 26):
Expected impact : 20-40% faster clean builds after initial cache population (up to 70%+ for favorable projects).
What it is : Xcode splits module compilation into explicit build tasks instead of implicit on-demand compilation. Enabled by default for Swift in Xcode 26.
The Problem with Implicit Modules (Pre-Xcode 16) :
When a compiler encounters an import, it builds the module on-demand:
Compile A.swift ─── needs UIKit ───→ (builds UIKit.pcm) ───→ continues
Compile B.swift ─── needs UIKit ───→ (waits for A to finish) ───→ uses cached
Compile C.swift ─── needs UIKit ───→ (waits) ───→ uses cached
Problems:
Explicitly Built Modules Solution :
Xcode now separates compilation into three phases:
Phase 1: SCAN Phase 2: BUILD MODULES Phase 3: COMPILE
┌──────────────────┐ ┌──────────────────────┐ ┌──────────────────┐
│ Scan A.swift │ │ Build UIKit.pcm │ │ Compile A.swift │
│ Scan B.swift │ → │ Build Foundation.pcm │ → │ Compile B.swift │
│ Scan C.swift │ │ Build SwiftUI.pcm │ │ Compile C.swift │
└──────────────────┘ └──────────────────────┘ └──────────────────┘
(fast) (parallel) (parallel)
Benefits :
Enable/Disable (if needed):
Build Settings → Explicitly Built Modules → YES (default in Xcode 26 for Swift)
Module Variants (WWDC 2024-10171)
The same module may be built multiple times with different settings:
Build Log:
Compile Clang module 'UIKit' (hash: abc123) ← Variant 1
Compile Clang module 'UIKit' (hash: def456) ← Variant 2
Compile Swift module 'UIKit' (hash: ghi789) ← Variant 3
Common causes of variants :
Diagnose variants :
Product → Perform Action → Build with Timing SummaryReduce variants (unify settings at project/workspace level):
# Check for macro differences
grep "GCC_PREPROCESSOR_DEFINITIONS" project.pbxproj
# Move target-specific macros to project level where possible
Project → Build Settings → Preprocessor Macros → [unify here]
Example (from WWDC 2024-10171):
Before: 4 UIKit variants (2 Swift × 2 Clang)
After: 2 UIKit variants (unified settings)
Impact: Fewer module builds = faster incremental builds
Expected impact : 10-30% faster builds by reducing duplicate module compilation.
Note: Swift Build (Xcode 26+): Xcode now uses Swift Build, Apple's open-source build engine. This provides more predictable builds, better SPM integration, and cross-platform support (Linux, Windows, Android). No configuration needed.
Required steps :
Baseline (before changes):
xcodebuild clean build -scheme YourScheme 2>&1 | tee baseline.log
Apply ONE optimization at a time
Measure improvement :
xcodebuild clean build -scheme YourScheme 2>&1 | tee optimized.log
Compare :
# Extract build time from logs
grep "Build succeeded" baseline.log
grep "Build succeeded" optimized.log
Example :
Baseline: Build succeeded (247.3 seconds)
Optimized: Build succeeded (156.8 seconds)
Improvement: 90.5 seconds (36.6% faster)
Before optimization :
After optimization :
Critical path : Should be visibly shorter.
Baseline :
Optimizations applied :
Result :
Baseline :
Optimizations applied :
Result :
Mistake : "I think this will help" → make change → no measurement.
Why bad : Placebo improvements, wasted time, actual regressions unnoticed.
Fix : Always measure before → change one thing → measure after.
Mistake : Set Release to incremental compilation for "faster builds".
Why bad : Release builds should optimize for runtime performance, not build speed. You ship Release builds to users.
Fix : Only optimize Debug builds for speed. Keep Release optimized for runtime.
Mistake : Remove legitimate dependencies to "make builds parallel".
Why bad : Build errors, undefined behavior, race conditions.
Fix : Only parallelize truly independent targets. Use Build Timeline to identify safe opportunities.
Mistake : Enable parallel scripts but don't declare inputs/outputs.
Why bad : Data races, non-deterministic build failures, incorrect builds.
Fix : First enable ENABLE_USER_SCRIPT_SANDBOXING = YES, fix all errors, THEN enable FUSE_BUILD_SCRIPT_PHASES.
Check :
xcodebuild clean)Check :
Check :
-warn-long-function-bodies 100 (with hyphen)# Find slowest files to compile
xcodebuild -workspace YourApp.xcworkspace \
-scheme YourScheme \
clean build \
OTHER_SWIFT_FLAGS="-Xfrontend -debug-time-function-bodies" 2>&1 | \
grep ".[0-9]ms" | \
sort -nr | \
head -20
Output :
247.3ms MyViewModel.swift:42:1 func calculateTotal
156.8ms LoginView.swift:18:3 var body
89.2ms NetworkManager.swift:67:1 func handleResponse
...
Action : Add explicit types to slowest functions.
# From build log
Build target 'MyApp' (project 'MyApp')
Compile Swift source files (128.4 seconds)
Link MyApp (12.3 seconds)
Run custom shell script (6.7 seconds)
Action : Optimize the longest phase first.
Before considering your build optimized:
Measurement
Compilation Settings
Parallelization
Xcode 26+ (if applicable)
COMPILATION_CACHE_ENABLE_CACHING)WWDC : 2018-408, 2022-110364, 2024-10171, 2025-247
Docs : /xcode/improving-the-speed-of-incremental-builds, /xcode/building-your-project-with-explicit-module-dependencies
Tools : Xcode Build Timeline (Xcode 14+), Build with Timing Summary (Product → Perform Action), Modules Report (Xcode 16+), Instruments Time Profiler
Remember : Build performance optimization is about systematic measurement and targeted improvements. Optimize the critical path first, measure everything, and verify improvements in the Build Timeline.
Weekly Installs
133
Repository
GitHub Stars
681
First Seen
Jan 21, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
opencode117
codex112
gemini-cli110
cursor109
claude-code108
github-copilot107
ESLint迁移到Oxlint完整指南:JavaScript/TypeScript项目性能优化工具
1,600 周安装
投资组合管理器 - 实时持仓分析与再平衡建议 | Alpaca API集成
382 周安装
Google Ads 付费广告设置与优化指南:从 PMF 测试到转化驱动的完整策略
392 周安装
Roblox游戏开发指南:Luau脚本、多人游戏、UI设计、盈利策略与性能优化
381 周安装
Neki:PlanetScale 分片式 Postgres 数据库,实现水平扩展与高可用性
384 周安装
json-render-react:JSON转React组件渲染器,Vercel Labs出品,动态UI构建利器
391 周安装
Cloudflare Worker 基础技术栈配置指南:Hono + Vite + Wrangler 最佳实践
394 周安装