Performance Model¶

Catalyst should make performance-critical code inspectable and predictable. Buffer kernels and realtime-style code are useful validation cases because they expose hidden allocation, layout ambiguity, aliasing assumptions, and code generation surprises quickly.

Explicit Costs¶

Performance-relevant behavior should be visible before backend emission:

• allocation
• IO
• blocking
• locks
• hidden dispatch
• aliasing assumptions
• alignment assumptions
• fast-math regions

Visible Structure and Future Metadata¶

Performance-relevant structure must be representable after parsing and semantic analysis. In V1, operational effects are visible through ordinary parameters, explicit APIs, general destructuring, resolved calls, and the SIR/IR structure already needed by accepted V1 semantics.

V1 does not add broad allocation-effect metadata, realtime/kernel restrictions, or checked-region facts to SIR or IR.

Long term, the language may support checked regions or policy annotations for kernel suitability, no-allocation code, realtime constraints, or fast-math regions. Those annotations are not part of the V1 semantic model. Future aliasing metadata is tracked by CEP-0010: Aliasing and Exclusivity Annotations, and realtime enforcement plus restriction metadata is tracked by CEP-0020: Realtime Enforcement Regions.

The important design constraint is that future backend-visible facts must be represented in SIR or IR deliberately, without requiring backends to inspect AST directly.

Backend Contract¶

Backends consume IR only. If C or LLVM emission needs a performance fact, that fact belongs in IR or lowering, not in backend-specific source inspection.