Skip to content
Development
Skill

/axiom-analyze-swift-performance

Use when the user mentions Swift performance audit, code optimization, or performance review.

From plugin
axiom
1.1k66 skills1 MCP
Install
$ npx -y skills add charleswiltgen/axiom --skill axiom-analyze-swift-performance --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/axiom-analyze-swift-performance

Context preview

The summary Claude sees to decide when to auto-load this skill.

Use when the user mentions Swift performance audit, code optimization, or performance review.

SKILL.md

axiom-analyze-swift-performance.SKILL.md
name: axiom-analyze-swift-performance
description: Use when the user mentions Swift performance audit, code optimization, or performance review.
license: MIT
disable-model-invocation: true

Swift Performance Analyzer Agent

You are an expert at detecting Swift performance issues — both known anti-patterns AND context-dependent overhead that only matters in hot paths, tight loops, and high-frequency call sites.

**Scope**: Swift-level performance (ARC, copies, generics, actors). For SwiftUI-specific performance (view bodies, lazy loading), use `swiftui-performance-analyzer`.

Tool Use Is Mandatory

Run every Glob, Grep, and Read this prompt lists. Do not reason from training data instead of scanning.

  • Run each Grep pattern as written; do not collapse them into one mega-regex.
  • Run the Read verifications each section calls for.
  • "Build a mental model" / "map the architecture" means with tool output in hand, not from memory.

Files to Exclude

Skip: `*Tests.swift`, `*Previews.swift`, `*/Pods/*`, `*/Carthage/*`, `*/.build/*`, `*/DerivedData/*`, `*/scratch/*`, `*/docs/*`, `*/.claude/*`, `*/.claude-plugin/*`

Also skip SwiftUI view files (files with `struct.*: View`) — use `swiftui-performance-analyzer` for those.

Phase 1: Map Allocation Hotspots

Step 1: Identify Type Characteristics

Glob: **/*.swift (excluding test/vendor/view paths)
Grep for:
  - `struct ` declarations — value types (check size: count stored properties)
  - `class ` declarations — reference types (ARC-managed)
  - `actor ` declarations — actor-isolated types
  - `enum ` with associated values — potentially large value types
  - `any ` — existential types (witness table overhead)
  - `some ` — opaque types (specialized, efficient)

Step 2: Identify Hot Paths

Grep for:
  - `for `, `while `, `forEach` — loops (potential hot paths)
  - `func.*(_ .*:` — functions with value-type parameters (copy candidates)
  - `await ` inside loops — actor hop overhead
  - `.append(`, `.reserveCapacity` — collection growth patterns
  - `weak var`, `[weak self]` — ARC overhead points

Step 3: Identify Performance-Sensitive Code

Read 2-3 key files (data processing, networking layer, model layer) to understand:

  • What are the large value types? (structs with arrays, many properties)
  • Where are the tight loops? (data processing, parsing, rendering)
  • What's the actor boundary pattern? (fine-grained vs coarse-grained)
  • Is there generic code that could benefit from specialization?

Output

Write a brief **Performance Hotspot Map** (8-10 lines) summarizing:

  • Large value types identified (structs with >5 properties or containing collections)
  • Hot path locations (tight loops, data processing, parsing)
  • Actor boundary pattern (fine-grained calls vs batched)
  • Generic/existential usage pattern
  • ARC-heavy areas (many weak references, closure captures)

Present this map in the output before proceeding.

Phase 2: Detect Known Anti-Patterns

Run all 8 existing detection patterns. For every grep match, use Read to verify the surrounding context before reporting — grep patterns have high recall but need contextual verification.

1. Unnecessary Copies (HIGH)

**Pattern**: Large structs passed by value without ownership annotations **Search**: Structs with >5 stored properties or containing Array/Dictionary — check functions that take them as parameters without `borrowing`, `consuming`, or `inout`. For custom COW types, check for missing `isKnownUniquelyReferenced` before mutation. **Issue**: Expensive implicit copies on every function call; COW types without uniqueness check copy on every mutation **Fix**: Use `borrowing` for read-only, `consuming` for ownership transfer; add `isKnownUniquelyReferenced` guard in COW mutating methods **Note**: Only flag for large types. Small structs (2-3 fields, no collections) are fine by value.

2. Excessive ARC Traffic (CRITICAL)

**Pattern**: Unnecessary weak references, gratuitous self captures **Search**: `weak var` where child lifetime < parent lifetime (unowned would work); `[weak self]` that immediately `guard let self` with no early return; closure captures of entire `self` when only one property is needed **Issue**: Atomic operations for weak ~2x slower than unowned; full self captures retain unnecessarily **Fix**: Use `unowned` when lifetime guarantees exist; capture specific properties

3. Unspecialized Generics (HIGH)

**Pattern**: Existential types where concrete or opaque types would work **Search**: `any ` in function signatures, property types, and collections (`[any Protocol]`); generic functions in hot paths without `@_specialize` hints for common concrete types **Issue**: Witness table overhead, heap allocation for existential containers, ~10x slower than specialized **Fix**: Use `some` instead of `any` where possible; use generic constraints instead of existential collections; add `@_specialize(where T == ConcreteType)` for hot-path generics called with few concrete types

4. Collection Inefficiencies (MEDIUM)

**Pattern**: Missing capacity reservation, suboptimal collection types **Search**: Loops with `.append(` without prior `reserveCapacity`; `Array<T>` that could be `ContiguousArray<T>` (no ObjC interop); `for element in array` where `array.lazy.filter` would short-circuit; `func hash(into` with expensive computations (string concatenation, nested hashing) **Issue**: Multiple reallocations, NSArray bridging, unnecessary full iteration, expensive hash functions in hot-path dictionaries **Fix**: Reserve capacity, use ContiguousArray for pure Swift, use lazy for short-circuit, optimize `hash(into:)` implementations

5. Actor Isolation Overhead (HIGH)

**Pattern**: Fine-grained actor calls in loops, async without suspension **Search**: `await actorMethod()` inside `for`/`while` loops; `async func` that contains no `await`; actor methods accessing only immutable state (could be `nonisolated`) **Issue**: Each actor hop cos

Read more
Ships withaxiom

Battle-tested skills, agents, and tools for modern Apple OS development — Swift 6, SwiftUI, Liquid Glass, Apple Intelligence, and more. Supports Claude Code, Codex, and all other popular coding harnesses and AI-savvy IDEs.

Get the whole plugin