Skip to content

Perf #8: Verify precomputed NamedTuple is already type-stable#154

Open
hmzh-khn wants to merge 2 commits into
perf/10-typed-k-eval-buffersfrom
perf/08-concrete-precomputed
Open

Perf #8: Verify precomputed NamedTuple is already type-stable#154
hmzh-khn wants to merge 2 commits into
perf/10-typed-k-eval-buffersfrom
perf/08-concrete-precomputed

Conversation

@hmzh-khn

Copy link
Copy Markdown
Collaborator

Summary

Investigation for Perf #8 (concrete type for NonlinearSolver.precomputed NamedTuple)
found that no refactor is needed — the NamedTuple approach is already fully type-stable.

Investigation Findings

The task hypothesized that the TC<:NamedTuple type parameter in NonlinearSolver{TP, TC}
could cause inference issues when the solver is passed through generic functions. Empirical
testing with @code_warntype and @inferred proved this is NOT the case:

  1. isconcretetype(typeof(solver.precomputed)) returns true — the NamedTuple type
    is fully concrete with all field types known at compile time
  2. All 11 fields in the precomputed NamedTuple have concrete types
  3. @inferred passes for field access patterns used in solve_raw and run_nonlinear_solver
  4. Julia specializes on concrete NamedTuple types regardless of ::NamedTuple annotations
    in function signatures (as in run_nonlinear_solver)

Why no refactor is needed

NamedTuple field access is resolved at compile time when the concrete NamedTuple type is
known. Since NonlinearSolver{TP, TC} carries the full TC type parameter, any function
taking a NonlinearSolver will be specialized on the concrete NamedTuple type. The
::NamedTuple annotation in run_nonlinear_solver is just a type constraint — Julia still
dispatches and specializes on the concrete type of the argument.

Replacing the NamedTuple with a concrete struct would add code complexity without any
performance benefit.

Changes

  • test/test_type_stability.jl: Added 15 new tests in "NonlinearSolver.precomputed NamedTuple is type-stable" testset:
    • Verifies solver and precomputed types are fully concrete (isconcretetype)
    • Verifies every precomputed field has a concrete type
    • Verifies @inferred passes for field access from NonlinearSolver
    • Verifies @inferred passes through ::NamedTuple annotation dispatch

Testing

  • All 1356 tests pass (julia --project=. -e 'using Pkg; Pkg.test()')
  • New tests specifically validate type stability with @inferred
  • No source code changes — tests only

Changelog

  • 2026-02-16: Initial PR — investigation proves NamedTuple is type-stable, adds guard tests

claude and others added 2 commits February 16, 2026 16:02
Investigation for Perf #8 (concrete type for precomputed field) found
that the NamedTuple approach is already type-stable:

1. typeof(solver.precomputed) is concrete — isconcretetype returns true
2. All NamedTuple fields have concrete types
3. @inferred confirms field access is resolved at compile time
4. Julia specializes on concrete NamedTuple types even through
   ::NamedTuple annotations (as in run_nonlinear_solver)

No refactor to a concrete struct is needed. This commit adds tests
that document and guard this stability property.

Tests verify:
- Solver and precomputed types are fully concrete
- Every precomputed field has a concrete type
- @inferred passes for field access patterns used in solve_raw
- Specialization works through ::NamedTuple dispatch annotations

Co-Authored-By: Claude Opus 4.6 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants