type-design-performance

Type Design for Performance

When to Use This Skill

Use this skill when:

• Designing new types and APIs
• Reviewing code for performance issues
• Choosing between class, struct, and record
• Working with collections and enumerables

---

Core Principles

1. Seal your types - Unless explicitly designed for inheritance
2. Prefer readonly structs - For small, immutable value types
3. Prefer static pure functions - Better performance and testability
4. Defer enumeration - Don't materialize until you need to
5. Return immutable collections - From API boundaries

---

Seal Classes by Default

Sealing classes enables JIT devirtualization and communicates API intent.

// DO: Seal classes not designed for inheritance
public sealed class OrderProcessor
{
    public void Process(Order order) { }
}

// DO: Seal records (they're classes)
public sealed record OrderCreated(OrderId Id, CustomerId CustomerId);

// DON'T: Leave unsealed without reason
public class OrderProcessor  // Can be subclassed - intentional?
{
    public virtual void Process(Order order) { }  // Virtual = slower
}

Benefits:

• JIT can devirtualize method calls
• Communicates "this is not an extension point"
• Prevents accidental breaking changes

---

Readonly Structs for Value Types

Structs should be readonly when immutable. This prevents defensive copies.

// DO: Readonly struct for immutable value types
public readonly record struct OrderId(Guid Value)
{
    public static OrderId New() => new(Guid.NewGuid());
    public override string ToString() => Value.ToString();
}

// DO: Readonly struct for small, short-lived data
public readonly struct Money
{
    public decimal Amount { get; }
    public string Currency { get; }

    public Money(decimal amount, string currency)
    {
        Amount = amount;
        Currency = currency;
    }
}

// DON'T: Mutable struct (causes defensive copies)
public struct Point  // Not readonly!
{
    public int X { get; set; }  // Mutable!
    public int Y { get; set; }
}