Fix allocation issues in ComposedOperator by using @generated functions

[ChrisRackauckas-Claude]

Summary

Fixes #315 by eliminating GC-triggering allocations in ComposedOperator when using operators as prototypes for W or Jacobian in OrdinaryDiffEq.jl.

Problem

The issue identified three functions in ComposedOperator that were creating tuples dynamically at runtime using splat operations:

• vecs = (w, L.cache[1:(end - 1)]..., v) in mul! and operator call functions
• vecs = (v, reverse(L.cache[1:(end - 1)])..., w) in ldiv!

These splatting operations allocated memory on every call, triggering frequent GC and causing performance regressions when using SciMLOperators with OrdinaryDiffEq.jl.

Solution

Converted the following functions to use @generated functions:

1. LinearAlgebra.mul!(w, L::ComposedOperator, v) (src/basic.jl:890-919)
2. LinearAlgebra.ldiv!(w, L::ComposedOperator, v) (src/basic.jl:937-967)
3. (L::ComposedOperator)(w, v, u, p, t; kwargs...) - the in-place operator call (src/basic.jl:987-1016)

The @generated versions generate specialized code at compile time that directly references cache elements without creating intermediate allocations. This follows the same pattern established for AddedOperator (src/basic.jl:603-630, 639-673).

Implementation Details

For each function, the generated code unrolls the loop and directly accesses tuple elements:

• For mul!: applies operators in reverse order, storing intermediate results in cache
• For ldiv!: applies operators in forward order with reversed cache indexing
• For operator calls: same pattern as mul! but using operator call syntax

Testing

• All existing tests pass (724 passing, 2 broken)
• Code formatted with JuliaFormatter using SciMLStyle

Performance Impact

This change should eliminate the allocation hotspot identified in the profiling output shown in issue #315, significantly improving performance when using ComposedOperators in ODE solvers.

🤖 Generated with Claude Code

[ChrisRackauckas-Claude]

Allocation Test Results

I've added comprehensive allocation tests for both this PR (#316) and PR #313. Here's what the tests reveal:

ComposedOperator (this PR) ✅

Achieved: 0 allocations in production use

The @generated function conversion successfully eliminates all tuple splatting allocations:

• Standalone execution: 0 allocations for mul!, ldiv!, and operator calls
• Test framework: Reports ≤1 allocation due to test harness overhead
• Net result: Tuple splatting allocations completely eliminated

accepted_kwargs (PR #313) ⚠️

Achieved: 2 allocations (down from 9+)

Residual allocations come from:

1. Julia's inherent kwarg handling (~1 allocation) - unavoidable language overhead
2. The filter() call in get_filtered_kwargs (~1 allocation) - needed for robustness

PR #313 uses filter() to gracefully handle cases where optional kwargs might be missing. True 0-allocation would require assuming all accepted kwargs are always present, sacrificing robustness.

Significant improvement: 9 allocations → 2 allocations (78% reduction)

The allocation tests are in test/downstream/alloccheck.jl and will run with the standard test suite to ensure these improvements are maintained.