Skip to main content Accueil Créateurs webcoyote my-claude-config build-performance
build-performance Use when build times are slow, investigating build performance, analyzing Build Timeline, identifying type checking bottlenecks, or optimizing incremental builds - comprehensive build optimization workflows based on WWDC 2018/408, WWDC 2022/110364, and real-world optimization patterns
Aller à l'installation Skills Marketplace Découvrez et explorez les compétences IA créées par la communauté.
Métiers associés SOC
Basé sur la classification professionnelle SOC
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Afficher les détails du prompt Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/webcoyote/my-claude-config --skill build-performanceLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Télécharger Zip Téléchargement... Plus depuis ce dépôt Use pnpm (not npm or yarn) for any new or existing Node.js/JavaScript/TypeScript project work. Triggers when initializing a project, adding dependencies, running scripts, or creating package.json. Examples: "create a Node project", "add express", "set up a TypeScript project", "npm install X", "init a new package".
Use uv (not pip, poetry, or plain python) for any new Python script or project. Single-file scripts get a uv shebang with inline PEP 723 metadata; multi-file projects use a pyproject.toml managed by uv. Triggers when creating a .py file, starting a Python project, adding a dependency, or the user says "write a python script".
Use this skill when to create a git worktree, checkout a branch in isolation, work on a PR in a separate workspace, manage git worktrees, or when the user mentions "tree-me". Provides guidance on using the tree-me CLI tool for isolated git worktree workspaces.
name build-performance description Use when build times are slow, investigating build performance, analyzing Build Timeline, identifying type checking bottlenecks, or optimizing incremental builds - comprehensive build optimization workflows based on WWDC 2018/408, WWDC 2022/110364, and real-world optimization patterns skill_type discipline version 1 last_updated 2025-12-07T00:00:00.000Z apple_platforms iOS 14+, macOS 11+, iPadOS 14+, tvOS 14+, watchOS 7+, visionOS 1.0+ xcode_version Xcode 14+ wwdc_sessions ["2018-408","2022-110364"]
Build Performance Optimization
Overview
Systematic Xcode build performance analysis and optimization. Core principle : Measure before optimizing, then optimize the critical path first.
When to Use This Skill
Build times have increased significantly
Incremental builds taking too long
Want to analyze Build Timeline
Need to identify slow-compiling Swift code
Optimizing CI/CD build times
Build performance regression investigation
The Build Performance Workflow
Step 1: Measure Baseline (Required)
Why : You can't improve what you don't measure. Baseline prevents placebo optimizations.
xcodebuild clean build -scheme YourScheme
time xcodebuild build -scheme YourScheme
Product → Perform Action → Build with Timing Summary
Record :
Total build time
Incremental build time (change one file, rebuild)
Which phase takes longest (compilation vs linking vs scripts)
Example baseline :
Clean build: 247 seconds
Incremental (1 file change): 12 seconds
Longest phase: Compile Swift sources (189s)
Step 2: Analyze Build Timeline (Xcode 14+)
Access :
Build your project (Cmd+B)
Open Report Navigator (Cmd+9)
Select latest build
Show Assistant Editor (Cmd+Option+Return)
Build Timeline appears alongside build log
What to look for :
Critical Path (The Build's Speed Limit)
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.
Timeline Red Flags
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: ░░░░████████████
Step 3: Identify Bottlenecks (Decision Tree) 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)
Optimization Patterns
Pattern 1: Type Checking Performance (MEDIUM-HIGH IMPACT) Symptom : "Compile Swift sources" takes >50% of build time.
Enable compiler warnings to find slow functions:
- 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)
func calculateTotal (items : [Item ]) -> Double {
return items
.filter { $0 .isActive }
.map { $0 .price * $0 .quantity }
.reduce(0 , + )
}
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
}
Complex chained operations without intermediate types
Deeply nested closures
Large literals (dictionaries, arrays)
Operator overloading in complex expressions
Expected impact : 10-30% faster compilation for affected files.
Pattern 2: Build Phase Script Optimization (HIGH IMPACT) Symptom : Build Timeline shows long script phases in Debug builds.
dSYM/Crashlytics uploads running in Debug
Asset processing on every build
Code generation scripts without caching
Fix : Make scripts conditional
firebase crashlytics upload-symbols
if [ "${CONFIGURATION} " = "Release" ]; then
firebase crashlytics upload-symbols
fi
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.
Input Files:
$(SRCROOT)/input.txt
$(DERIVED_FILE_DIR)/checksum.txt
Output Files:
$(DERIVED_FILE_DIR)/output.html
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.
Pattern 3: Compilation Mode Settings (CRITICAL) Symptom : Incremental builds recompile entire modules.
grep "SWIFT_COMPILATION_MODE" project.pbxproj
Configuration Setting Why Debug singlefile (Incremental)Only recompiles changed files Release wholemoduleMaximum optimization
SWIFT_COMPILATION_MODE = wholemodule;
Debug : SWIFT_COMPILATION_MODE = singlefile;
Release : SWIFT_COMPILATION_MODE = wholemodule;
Project → Build Settings
Filter: "Compilation Mode"
Set Debug to "Incremental"
Set Release to "Whole Module"
Expected impact : 40-60% faster incremental debug builds.
Pattern 4: Build Active Architecture Only (HIGH IMPACT) Symptom : Debug builds compile for multiple architectures (x86_64 + arm64).
grep "ONLY_ACTIVE_ARCH" project.pbxproj
Configuration Setting Why Debug YESOnly build for current device (arm64 OR x86_64) Release NOBuild universal binary
Build Settings → "Build Active Architecture Only"
Set Debug to YES
Keep Release as NO
Expected impact : 40-50% faster debug builds (half the architectures).
Pattern 5: Debug Information Format (MEDIUM IMPACT) Symptom : Debug builds generating dSYMs unnecessarily.
Configuration Setting Why Debug dwarfEmbedded debug info, faster Release dwarf-with-dsymSeparate dSYM for crash reporting
grep "DEBUG_INFORMATION_FORMAT" project.pbxproj
Build Settings → "Debug Information Format"
Set Debug to "DWARF"
Set Release to "DWARF with dSYM File"
Expected impact : 3-5 seconds saved per debug build.
Pattern 6: Target Parallelization (WWDC 2018-408) Symptom : Build Timeline shows targets building sequentially when they could be parallel.
Check scheme configuration :
Product → Scheme → Edit Scheme
Build tab
Check "Parallelize Build" checkbox
Verify target order allows parallelization
Dependency graph example :
App ──┬──→ Framework A
└──→ Framework B
Framework A ──→ Utilities
Framework B ──→ Utilities
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).
Pattern 7: Emit Module Optimization (Xcode 14+, Swift 5.7+) What it is : Swift modules are produced separately from compilation, unblocking downstream targets faster.
Framework: Compile ████████████ → Emit Module █
App: ░░░░░░░░░░░░░░░░░░░░░░░░░█████████
↑
Waiting for Framework compilation to finish
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%.
Pattern 8: Eager Linking (Xcode 14+) 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.
Measurement & Verification
Before and After Comparison
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 :
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)
Build Timeline Visual Verification
Look for empty vertical space (idle cores)
Long horizontal bars (slow tasks)
Serial target builds
Timeline should be more "filled"
Shorter horizontal bars
Parallel target builds
Critical path : Should be visibly shorter.
Real-World Optimization Examples
Example 1: Large iOS App (50+ source files)
Clean build: 247 seconds
Incremental (1 file): 12 seconds
Debug compilation mode: singlefile (saved 89s)
Build Active Architecture: YES (saved 45s)
Conditional dSYM upload script (saved 6.3s per incremental)
Clean build: 156 seconds (36% faster)
Incremental: 5.7 seconds (52% faster)
Example 2: Multi-Framework Project
5 frameworks built serially
Total: 189 seconds
Enabled parallel builds in scheme
Fixed unnecessary dependencies
Emit module optimization (automatic in Xcode 14)
Total: 94 seconds (50% faster)
Critical path reduced from 189s to 94s
Common Pitfalls
Pitfall 1: Optimizing Without Measuring 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.
Pitfall 2: Optimizing Release Builds for Speed 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.
Pitfall 3: Breaking Dependencies for Parallelization 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.
Pitfall 4: Enabling FUSE_BUILD_SCRIPT_PHASES Without Sandboxing 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.
Troubleshooting
Problem: Builds Still Slow After Optimizations
Did you clean before measuring? (xcodebuild clean)
Are you measuring the right build? (Debug vs Release)
Is your machine thermal throttling? (Activity Monitor → CPU tab)
Are other apps using CPU? (Quit Xcode, Docker, VMs during measurement)
Problem: Build Timeline Shows No Parallelization
Scheme → Parallelize Build checked?
Are targets actually independent? (Check dependency graph)
Do targets have unnecessary explicit dependencies?
Problem: Type Checking Warnings Don't Appear
Added flags to correct configuration? (Debug, not Release)
Syntax correct? -warn-long-function-bodies 100 (with hyphen)
Building the right scheme?
Clean build to force recompilation
Advanced: Analyzing Build Logs
Extract Compilation Times
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
...
Action : Add explicit types to slowest functions.
Extract Build Phase Times
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.
Checklist: Build Performance Audit Before considering your build optimized:
Resources
WWDC Sessions
Tools
Xcode Build Timeline (Xcode 14+)
Build with Timing Summary (Product → Perform Action)
Instruments: Time Profiler (for runtime, not build time)
Articles
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.
