Repeated consumed materialization / Growing prefix is repeatedly materialized

Rule ID: performance.repeated-consumed-materialization@1.0.0. Availability below refers to source-scan at product 524fa07e.

V-PERF-03 — Repeated consumed materialization#

Repeated consumed materialization. It examines repeated work, allocation, traversal, retention, and scheduling cost.

Availability#

Not available in source-scan. There is no source-scan flag to activate this condition.

A separate experimental source preview recognizes a limited local pattern for this condition:

"$ANALYZER" experimental-scan <path> --rule performance.repeated-consumed-materialization --format json

Use the terminal from Installation, with ANALYZER set, and replace <path> with a Swift file or directory. This preview is not compiler-backed source-scan coverage.

Example and action#

Illustrative pattern only. This is not a complete runnable package or a reproduced source-scan result. Helper APIs and omitted context must be supplied by the application.

for chunk in chunks {
    output = Array(output + chunk)
}

Confirm the operation is on a relevant path and measure with representative input. Preserve evaluation order, laziness, errors and memory behavior when changing the algorithm.

var output: [Element] = []
for chunk in chunks { output.append(contentsOf: chunk) }

Intended analysis#

Intended reasoning: Relate a repeated operation to its input size, consumption and cost assumptions. An intended cost warning needs the loop bounds and actual collection behavior; syntax alone is not a measured runtime regression. Required evidence: cost, multiplicity, collection, allocation, and lifetime facts

Assumptions and unknown#

The relevant facts must be admitted for the selected immutable build world. Unknown aliases, external effects, unsupported source forms or incomplete consumers can prevent a conclusion. Availability in this workflow is stated above; the illustration does not expand that availability.

Evidence and interpretation#

The target catalog describes the intended condition. It is not evidence of an active source-scan diagnostic.

Historical evidence at 4558458d: recovery-required (historical qualification is incomplete and needs further evidence). That evidence has not been requalified for this product revision.

How we validate checks explains the evidence boundary. Foundations separates method assumptions from implementation claims.

V-PERF-11 — Growing prefix is repeatedly materialized#

Growing prefix is repeatedly materialized. It examines repeated work, allocation, traversal, retention, and scheduling cost.

Availability#

Not available in source-scan. There is no source-scan flag to activate this condition.

Example and action#

Illustrative pattern only. This is not a complete runnable package or a reproduced source-scan result. Helper APIs and omitted context must be supplied by the application.

for end in 1...items.count {
    consume(Array(items.prefix(end)))
}

Confirm the operation is on a relevant path and measure with representative input. Preserve evaluation order, laziness, errors and memory behavior when changing the algorithm.

for item in items { consumeNext(item) }

Intended analysis#

Intended reasoning: Relate a repeated operation to its input size, consumption and cost assumptions. An intended cost warning needs the loop bounds and actual collection behavior; syntax alone is not a measured runtime regression. Required evidence: cost, multiplicity, collection, allocation, and lifetime facts

Assumptions and unknown#

The relevant facts must be admitted for the selected immutable build world. Unknown aliases, external effects, unsupported source forms or incomplete consumers can prevent a conclusion. Availability in this workflow is stated above; the illustration does not expand that availability.

Evidence and interpretation#

The target catalog describes the intended condition. It is not evidence of an active source-scan diagnostic.

Historical evidence at 4558458d: recovery-required (historical qualification is incomplete and needs further evidence). That evidence has not been requalified for this product revision.

How we validate checks explains the evidence boundary. Foundations separates method assumptions from implementation claims.