xcode-compilation-analyzer

Name: xcode-compilation-analyzer
Author: AvdLee

2.8kinstalls45forks

How to install xcode-compilation-analyzer?

avdlee/xcode-build-optimization-agent-skill/xcode-compilation-analyzer

$npx -y skills add AvdLee/Xcode-Build-Optimization-Agent-Skill --skill xcode-compilation-analyzer

Installs into the current project.

Summary

Analyze Swift and mixed-language compile hotspots using build timing summaries and Swift frontend diagnostics, then produce a recommend-first source-level optimization plan. Use when a developer reports slow compilation, type-checking warnings, expensive clean-build compile phase

Files · 1

View on GitHub

SKILL.md

1	# Xcode Compilation Analyzer
2
3	Use this skill when compile time, not just general project configuration, looks like the bottleneck.
4
5	## Core Rules
6
7	- Start from evidence, ideally a recent `.build-benchmark/` artifact or raw timing-summary output.
8	- Prefer analysis-only compiler flags over persistent project edits during investigation.
9	- Rank findings by expected wall-clock impact, not cumulative compile-time impact. When compile tasks are heavily parallelized (sum of compile categories >> wall-clock median), note that fixing individual hotspots may improve parallel efficiency without reducing build wait time.
10	- When the evidence points to parallelized work rather than serial bottlenecks, label recommendations as "Reduces compiler workload (parallel)" rather than "Reduces build time."
11	- Do not edit source or build settings without explicit developer approval.
12
13	## What To Inspect
14
15	- `Build Timing Summary` output from clean and incremental builds
16	- long-running `CompileSwiftSources` or per-file compilation tasks
17	- `SwiftEmitModule` time -- can reach 60s+ after a single-line change in large modules; if it dominates incremental builds, the module is likely too large or macro-heavy
18	- `Planning Swift module` time -- if this category is disproportionately large in incremental builds (up to 30s per module), it signals unexpected input invalidation or macro-related rebuild cascading
19	- ad hoc runs with:
20	- `-Xfrontend -warn-long-expression-type-checking=<ms>`
21	- `-Xfrontend -warn-long-function-bodies=<ms>`
22	- deeper diagnostic flags for thorough investigation:
23	- `-Xfrontend -debug-time-compilation` -- per-file compile times to rank the slowest files
24	- `-Xfrontend -debug-time-function-bodies` -- per-function compile times (unfiltered, complements the threshold-based warning flags)
25	- `-Xswiftc -driver-time-compilation` -- driver-level timing to isolate driver overhead
26	- `-Xfrontend -stats-output-dir <path>` -- detailed compiler statistics (JSON) per compilation unit for root-cause analysis
27	- mixed Swift and Objective-C surfaces that increase bridging work
28
29	## Analysis Workflow
30
31	1. Identify whether the main issue is broad compilation volume or a few extreme hotspots.
32	2. Parse timing-summary categories and rank the biggest compile contributors.
33	3. Run the diagnostics script to surface type-checking hotspots:
34	```bash
35	python3 scripts/diagnose_compilation.py \
36	--project App.xcodeproj \
37	--scheme MyApp \
38	--configuration Debug \
39	--destination "platform=iOS Simulator,name=iPhone 16" \
40	--threshold 100 \
41	--output-dir .build-benchmark
42	```
43	This produces a ranked list of functions and expressions that exceed the millisecond threshold. Use the diagnostics artifact alongside source inspection to focus on the most expensive files first.
44	4. Map the evidence to a concrete recommendation list.
45	5. Separate code-level suggestions from project-level or module-level suggestions.
46
47	## Apple-Derived Checks
48
49	Look for these patterns first:
50
51	- missing explicit type information in expensive expressions
52	- complex chained or nested expressions that are hard to type-check
53	- delegate properties typed as `AnyObject` instead of a concrete protocol
54	- oversized Objective-C bridging headers or generated Swift-to-Objective-C surfaces
55	- header imports that skip framework qualification and miss module-cache reuse
56	- classes missing `final` that are never subclassed
57	- overly broad access control (`public`/`open`) on internal-only symbols
58	- monolithic SwiftUI `body` properties that should be decomposed into subviews
59	- long method chains or closures without intermediate type annotations
60
61	## Reporting Format
62
63	For each recommendation, include:
64
65	- observed evidence
66	- likely affected file or module
67	- expected wait-time impact (e.g. "Expected to reduce your clean build by ~2s" or "Reduces parallel compile work but unlikely to reduce build wait time")
68	- confidence
69	- whether approval is required before applying it
70
71	If the evidence points to project configuration instead of source, hand off to [`xcode-project-analyzer`](../xcode-project-analyzer/SKILL.md) by reading its SKILL.md and applying its workflow to the same project context.
72
73	## Preferred Tactics
74
75	- Suggest ad hoc flag injection through the build command before recommending persistent build-setting changes.
76	- Prefer narrowing giant view builders, closures, or result-builder expressions into smaller typed units.
77	- Recommend explicit imports and protocol typing when they reduce compiler search space.
78	- Call out when mixed-langu

People who liked this also viewed

6 picks

Type

xcode-compilation-analyzer

2.8kinstalls45forks

View on GitHub

How to install xcode-compilation-analyzer?

avdlee/xcode-build-optimization-agent-skill/xcode-compilation-analyzer

$npx -y skills add AvdLee/Xcode-Build-Optimization-Agent-Skill --skill xcode-compilation-analyzer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Xcode Compilation Analyzer
2
3	Use this skill when compile time, not just general project configuration, looks like the bottleneck.
4
5	## Core Rules
6
7	- Start from evidence, ideally a recent `.build-benchmark/` artifact or raw timing-summary output.
8	- Prefer analysis-only compiler flags over persistent project edits during investigation.
9	- Rank findings by expected wall-clock impact, not cumulative compile-time impact. When compile tasks are heavily parallelized (sum of compile categories >> wall-clock median), note that fixing individual hotspots may improve parallel efficiency without reducing build wait time.
10	- When the evidence points to parallelized work rather than serial bottlenecks, label recommendations as "Reduces compiler workload (parallel)" rather than "Reduces build time."
11	- Do not edit source or build settings without explicit developer approval.
12
13	## What To Inspect
14
15	- `Build Timing Summary` output from clean and incremental builds
16	- long-running `CompileSwiftSources` or per-file compilation tasks
17	- `SwiftEmitModule` time -- can reach 60s+ after a single-line change in large modules; if it dominates incremental builds, the module is likely too large or macro-heavy
18	- `Planning Swift module` time -- if this category is disproportionately large in incremental builds (up to 30s per module), it signals unexpected input invalidation or macro-related rebuild cascading
19	- ad hoc runs with:
20	- `-Xfrontend -warn-long-expression-type-checking=<ms>`
21	- `-Xfrontend -warn-long-function-bodies=<ms>`
22	- deeper diagnostic flags for thorough investigation:
23	- `-Xfrontend -debug-time-compilation` -- per-file compile times to rank the slowest files
24	- `-Xfrontend -debug-time-function-bodies` -- per-function compile times (unfiltered, complements the threshold-based warning flags)
25	- `-Xswiftc -driver-time-compilation` -- driver-level timing to isolate driver overhead
26	- `-Xfrontend -stats-output-dir <path>` -- detailed compiler statistics (JSON) per compilation unit for root-cause analysis
27	- mixed Swift and Objective-C surfaces that increase bridging work
28
29	## Analysis Workflow
30
31	1. Identify whether the main issue is broad compilation volume or a few extreme hotspots.
32	2. Parse timing-summary categories and rank the biggest compile contributors.
33	3. Run the diagnostics script to surface type-checking hotspots:
34	```bash
35	python3 scripts/diagnose_compilation.py \
36	--project App.xcodeproj \
37	--scheme MyApp \
38	--configuration Debug \
39	--destination "platform=iOS Simulator,name=iPhone 16" \
40	--threshold 100 \
41	--output-dir .build-benchmark
42	```
43	This produces a ranked list of functions and expressions that exceed the millisecond threshold. Use the diagnostics artifact alongside source inspection to focus on the most expensive files first.
44	4. Map the evidence to a concrete recommendation list.
45	5. Separate code-level suggestions from project-level or module-level suggestions.
46
47	## Apple-Derived Checks
48
49	Look for these patterns first:
50
51	- missing explicit type information in expensive expressions
52	- complex chained or nested expressions that are hard to type-check
53	- delegate properties typed as `AnyObject` instead of a concrete protocol
54	- oversized Objective-C bridging headers or generated Swift-to-Objective-C surfaces
55	- header imports that skip framework qualification and miss module-cache reuse
56	- classes missing `final` that are never subclassed
57	- overly broad access control (`public`/`open`) on internal-only symbols
58	- monolithic SwiftUI `body` properties that should be decomposed into subviews
59	- long method chains or closures without intermediate type annotations
60
61	## Reporting Format
62
63	For each recommendation, include:
64
65	- observed evidence
66	- likely affected file or module
67	- expected wait-time impact (e.g. "Expected to reduce your clean build by ~2s" or "Reduces parallel compile work but unlikely to reduce build wait time")
68	- confidence
69	- whether approval is required before applying it
70
71	If the evidence points to project configuration instead of source, hand off to [`xcode-project-analyzer`](../xcode-project-analyzer/SKILL.md) by reading its SKILL.md and applying its workflow to the same project context.
72
73	## Preferred Tactics
74
75	- Suggest ad hoc flag injection through the build command before recommending persistent build-setting changes.
76	- Prefer narrowing giant view builders, closures, or result-builder expressions into smaller typed units.
77	- Recommend explicit imports and protocol typing when they reduce compiler search space.
78	- Call out when mixed-langu

People who liked this also viewed

6 picks

Type