Functions — Optimize & Reconcile¶

"Extract till you drop" and "keep functions small" are the right default. But every function boundary has a cost: a call, possibly an allocation, possibly a missed inlining opportunity. This file reconciles clean-function discipline with performance. The principled stance: stay clean by default; collapse a boundary only when a profiler — not intuition — names it as the bottleneck. Each scenario gives a concrete situation, the measurement that settles the argument, and the resolution that keeps the code as clean as the numbers allow.

Table of Contents¶

1. Function-call overhead is not free — but inlining usually erases it
2. Go's inlining budget and //go:noinline
3. JVM JIT inlining thresholds — when "extract" survives compilation
4. Python's per-call cost — the language where small functions actually hurt
5. "Extract till you drop" vs hot-path inlining
6. Passing large structs by value vs pointer (Go)
7. Boxing on the argument path (Java)
8. Closures and the allocation cost of higher-order helpers
9. When a parameter object adds an allocation
10. Tail calls — what the runtime will and won't optimize
11. The cost of returning Optional / error / Result wrappers vs raw values
12. Guard-clause helpers that defeat inlining

13. Recursion vs iteration for deep call chains

14. Rules of Thumb

15. Related Topics

Scenario 1 — Function-call overhead is not free — but inlining usually erases it¶

A reviewer objects to extracting a one-line helper called inside a tight loop: "that's a function call per iteration, it'll be slow." Is it?

// Extracted, "clean":
func isVowel(c byte) bool {
    return c == 'a' || c == 'e' || c == 'i' || c == 'o' || c == 'u'
}

func countVowels(s string) int {
    n := 0
    for i := 0; i < len(s); i++ {
        if isVowel(s[i]) {
            n++
        }
    }
    return n
}

The raw cost of a call — push arguments, jump, set up a stack frame, return — is roughly 1–3 ns on a modern CPU when the call actually happens. Over a 100M-iteration loop that is 100–300 ms of pure call overhead, which sounds alarming. But the reviewer is reasoning about the unoptimized program. isVowel is tiny and leaf-level; every mainstream compiler will inline it, leaving zero call overhead.

Scenario 2 — Go's inlining budget and //go:noinline¶

Go's inliner is governed by a cost budget, not by line count. As of Go 1.20+ the default budget is 80 "nodes" (an internal AST-cost unit); a function whose body exceeds the budget is not inlined into its callers. A handful of constructs cost far more than they look and silently push a function over budget:

func priceOf(item Item) float64 {
    defer trace("priceOf")()        // `defer` makes the function non-inlinable
    if item.Qty == 0 {
        panic("zero qty")            // direct `panic` is costly in the budget
    }
    return item.Unit * float64(item.Qty)
}

Both defer and (historically) closures/panic in the body can disqualify inlining. The "clean" instinct — wrap everything in a tracing defer — turns a hot leaf function into a real call on every invocation.

func priceOf(item Item) float64 {
    return item.Unit * float64(item.Qty)   // inlinable; ~5 nodes
}

Scenario 3 — JVM JIT inlining thresholds — when "extract" survives compilation¶

The JVM inlines at runtime based on call frequency and bytecode size, controlled by these defaults (HotSpot, -XX:+PrintFlagsFinal):

A clean 30-line method may compile to ~120 bytes of bytecode — too big for MaxInlineSize, but fine for FreqInlineSize once it's hot. So extraction is free for hot code and only costs a real call for cold or megamorphic call sites.

// Extracted accessor in a hot pricing loop:
double lineTotal(OrderLine l) { return l.unitPrice() * l.quantity(); }

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining MyApp

Scenario 4 — Python's per-call cost — the language where small functions actually hurt¶

Python has no inliner. Every function call is a real, interpreted dispatch: build a frame object, bind arguments, push/pop the value stack. On CPython 3.11 a trivial call costs on the order of 30–60 ns — 10–50× more than the same call in compiled Go or warmed-up Java. In a 10M-element numeric loop, a per-element helper call can dominate runtime.

def _scale(x, factor):          # called 10M times
    return x * factor

result = [_scale(x, 1.8) for x in data]   # the call is the bottleneck

import numpy as np
result = data * 1.8        # ~100× faster than the Python loop; no per-element call at all

result = [x * 1.8 for x in data]   # no call frame per element

append = out.append
for x in data:
    append(x * 1.8)

Scenario 5 — "Extract till you drop" vs hot-path inlining¶

"Extract till you drop" (Robert Martin) says: keep extracting functions until each does one thing and you cannot meaningfully extract further. Taken literally on a hot path, it can produce a chain of one-line calls. Does the chain cost anything?

boolean eligible(User u) { return active(u) && verified(u) && inRegion(u); }
boolean active(User u)    { return u.status() == ACTIVE; }
boolean verified(User u)  { return u.emailVerified(); }
boolean inRegion(User u)  { return REGIONS.contains(u.region()); }

// Flattened: PrintInlining showed inRegion not inlined at depth 10 in the
// pricing loop (see bench PricingBench#eligibility, 22ns -> 6ns). Keep flat.
boolean eligible(User u) {
    return u.status() == ACTIVE && u.emailVerified() && REGIONS.contains(u.region());
}

Scenario 6 — Passing large structs by value vs pointer (Go)¶

Go passes everything by value, including structs. Clean Go often favors value receivers and value parameters because they're immutable and easy to reason about. But a large value parameter is copied on every call:

type Snapshot struct {       // 240 bytes: many fields + 3 [16]byte arrays
    // ...
}

func score(s Snapshot) float64 { ... }   // copies 240 bytes per call

for _, snap := range snapshots {         // 50M snapshots
    total += score(snap)
}

Copying 240 bytes is ~tens of bytes/ns memory bandwidth; across 50M calls the copies alone can add hundreds of milliseconds and evict useful data from L1.

func score(s *Snapshot) float64 { ... }   // copies 8 bytes (a pointer)

Scenario 7 — Boxing on the argument path (Java)¶

A clean generic helper accepts Object/boxed types, but the caller passes primitives in a hot loop. Each call autoboxes, allocating an Integer (or Double) per invocation:

<T> void record(Map<String, T> m, String k, T v) { m.merge(k, v, this::combine); }

for (int i = 0; i < 100_000_000; i++) {
    record(counts, key, i);   // autoboxes int -> Integer every iteration
}

Each boxed Integer outside the cache range (-128..127) is a heap allocation: ~16 bytes plus GC pressure. 100M allocations is gigabytes of churn and major GC pauses.

void recordInt(Map<String, Integer> m, String k, int v) { ... }
counts.merge(key, v, Integer::sum);   // still boxes the value, but no per-call lambda capture

Scenario 8 — Closures and the allocation cost of higher-order helpers¶

Higher-order functions (map, filter, callbacks) read beautifully. But a closure that captures variables is an allocation, and one created inside a loop allocates per iteration:

func process(items []Item, taxRate float64) {
    for _, it := range items {                 // 10M items
        apply(it, func(x float64) float64 {     // captures taxRate -> heap closure per item
            return x * (1 + taxRate)
        })
    }
}

A non-capturing function literal is a constant (zero allocation). A capturing one becomes a heap-allocated closure object in Go (and Java if it captures), and creating it inside the loop allocates 10M times.

// Created once, reused across all iterations:
withTax := func(x float64) float64 { return x * (1 + taxRate) }
for _, it := range items {
    apply(it, withTax)
}

func withTax(x, rate float64) float64 { return x * (1 + rate) }

Scenario 9 — When a parameter object adds an allocation¶

"Introduce Parameter Object" replaces a long parameter list with a single struct/record. Cleaner signature — but if the language heap-allocates the object and it's built per call in a hot path, you've traded register-passed scalars for an allocation:

@dataclass
class Bounds:
    lo: int
    hi: int

def clamp(value: int, bounds: Bounds) -> int:        # caller builds Bounds(0, 255) per call
    return max(bounds.lo, min(value, bounds.hi))

pixels = [clamp(p, Bounds(0, 255)) for p in raw]     # 1 object + attribute lookups per pixel

In Python every Bounds(0,255) is an object allocation plus two attribute lookups inside clamp. In Java, a non-escaping record may be eliminated by escape analysis (scalar replacement) — but only if EA fires. In Go, a small value struct is free (stays on the stack), so the smell is language-dependent.

bounds = Bounds(0, 255)                  # built once
pixels = [clamp(p, bounds) for p in raw]

Scenario 10 — Tail calls — what the runtime will and won't optimize¶

Tail-recursive code is often the cleanest expression of an iterative process. The trap: most mainstream runtimes here do not perform tail-call optimization (TCO), so a "clean" deep tail recursion overflows the stack instead of running in constant space.

def sum_to(n, acc=0):
    if n == 0:
        return acc
    return sum_to(n - 1, acc + n)   # tail call, but CPython does NOT optimize it

sum_to(1_000_000)   # RecursionError: maximum recursion depth exceeded

def sum_to(n):
    acc = 0
    for i in range(1, n + 1):
        acc += i
    return acc

Scenario 11 — The cost of returning Optional / error / Result wrappers vs raw values¶

Returning Optional<T> (Java) or a wrapped Result/error instead of a sentinel is a clean-code win: the absence of a value is in the type, not in a magic -1 or null. But the wrapper can allocate, and in a hot path that adds up.

// Clean: absence is explicit.
Optional<Customer> find(long id) { ... }

long count = 0;
for (long id : ids) {                  // 50M ids
    if (find(id).isPresent()) count++; // each find() may allocate an Optional
}

Optional is an object; outside escape-analysis elimination, each find allocates ~16 bytes. Go's (T, error) returns are allocation-free for the happy path (multi-value return, no wrapper), but constructing an error value (especially fmt.Errorf, which allocates) on a hot error path is costly.

Scenario 12 — Guard-clause helpers that defeat inlining¶

Guard clauses keep functions flat and readable. Extracting the guard into a validator helper can, however, make the caller too large to inline or add a surviving call on a hot path:

func transfer(from, to *Account, amount int64) error {
    if err := validate(from, to, amount); err != nil {   // helper does 5 checks + builds errors
        return err
    }
    from.balance -= amount
    to.balance += amount
    return nil
}

func validate(from, to *Account, amount int64) error {
    if from == nil { return errors.New("nil from") }
    if to == nil { return errors.New("nil to") }
    if amount <= 0 { return errors.New("non-positive amount") }
    if from.balance < amount { return ErrInsufficient }
    if from == to { return errors.New("same account") }
    return nil
}

validate is large (multiple errors.New calls, several branches) — well over Go's budget, so it won't inline. On the success path you pay a real call plus the cost of the inliner refusing to fold transfer into its caller.

func transfer(from, to *Account, amount int64) error {
    // Cheap predicate, inlinable, covers the hot success path:
    if from != nil && to != nil && from != to && amount > 0 && from.balance >= amount {
        from.balance -= amount
        to.balance += amount
        return nil
    }
    return transferError(from, to, amount)   // cold path: builds the specific error
}

Scenario 13 — Recursion vs iteration for deep call chains¶

Beyond tail calls (Scenario 10), ordinary (non-tail) recursion expresses tree/divide-and-conquer algorithms cleanly, but each frame costs memory and a call. On a hot, deep, or wide recursion the frame overhead and lack of inlining matter:

def fib(n):                       # exponential calls; each is a real Python frame
    if n < 2:
        return n
    return fib(n - 1) + fib(n - 2)

fib(35)   # ~29M calls, seconds of runtime — frame setup dominates

The cleanliness here is illusory: the recursion isn't just slow per call, it recomputes subproblems. The performance fix is also the clearer expression of intent.

from functools import lru_cache

@lru_cache(maxsize=None)
def fib(n):
    return n if n < 2 else fib(n - 1) + fib(n - 2)

Rules of Thumb¶

1. Clean is the default; performance is the exception you must justify with numbers. Never inline, denormalize, or unwind an abstraction on intuition — only on a profile.
2. The call is free until proven otherwise. Small leaf functions inline in Go and warm Java to identical machine code. Verify (-gcflags='-m', -XX:+PrintInlining) before believing a reviewer who says "that call is slow."
3. Know your language's call cost. Compiled (Go/Java warm): ~1–3 ns, usually inlined to 0. Python: ~30–60 ns, never inlined — the one place hand-inlining (or vectorizing) is legitimate.
4. Inlining has a budget. Go (~80 nodes), JVM (MaxInlineSize 35 B / FreqInlineSize 325 B / depth ~9). defer, megamorphic dispatch, and oversized bodies break it. Fix the blocker, don't merge the function.
5. Split functions on temperature, not just responsibility. Cheap-and-hot logic inline; expensive-and-cold (error construction, logging, tracing) extracted to a cold helper. Keeps both inlining and guard-clause clarity.
6. Pass small structs by value, large by pointer (Go) — but watch escape analysis. ≤ ~32 bytes: value (stack, no GC). Larger on a hot path: pointer. Always check moved to heap.
7. Hoist invariants out of loops — capturing closures, parameter objects, regex/Pattern, attribute lookups. This is the single most common "clean code that got slow" fix, and it keeps the code clean.
8. Beware silent allocations on the argument/return path: autoboxing (Java), capturing closures, Optional/fmt.Errorf per call. Use allocation profiling (-e alloc, -benchmem) to find them; carve a narrow fast path, keep the clean general API.
9. Don't rely on TCO in Python/Java/Go. Deep, unbounded recursion is a correctness hazard, not just a speed one — write the loop.
10. When recursion is slow, fix the algorithm first. Memoization/iteration usually collapses the call count, making per-call overhead moot, and is often clearer than the naive recursion.
11. Every earned ugliness gets a comment with its benchmark. A flattened hot path without a number is just unjustified mess to the next reader.

Related Topics¶

• README.md — the positive rules of clean functions this file reconciles with performance.
• find-bug.md — correctness bugs hiding in function boundaries (guard ordering, output args, temporal coupling).
• professional.md — senior judgment on function design trade-offs in real reviews.
• Chapter README — the Functions chapter overview and anti-pattern list.
• ../../functional-programming/README.md — allocation and call-cost profile of higher-order functions, closures, and immutable transforms.
• ../../refactoring/01-code-smells/01-bloaters/optimize.md — the companion treatment of allocation and indirection costs created by extraction-style refactorings.