Perf #8: Verify precomputed NamedTuple is already type-stable#154
Open
hmzh-khn wants to merge 2 commits into
Open
Perf #8: Verify precomputed NamedTuple is already type-stable#154hmzh-khn wants to merge 2 commits into
hmzh-khn wants to merge 2 commits into
Conversation
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]>
Co-Authored-By: Claude Opus 4.6 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Investigation for Perf #8 (concrete type for
NonlinearSolver.precomputedNamedTuple)found that no refactor is needed — the NamedTuple approach is already fully type-stable.
Investigation Findings
The task hypothesized that the
TC<:NamedTupletype parameter inNonlinearSolver{TP, TC}could cause inference issues when the solver is passed through generic functions. Empirical
testing with
@code_warntypeand@inferredproved this is NOT the case:isconcretetype(typeof(solver.precomputed))returnstrue— the NamedTuple typeis fully concrete with all field types known at compile time
@inferredpasses for field access patterns used insolve_rawandrun_nonlinear_solver::NamedTupleannotationsin 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 fullTCtype parameter, any functiontaking a
NonlinearSolverwill be specialized on the concrete NamedTuple type. The::NamedTupleannotation inrun_nonlinear_solveris just a type constraint — Julia stilldispatches 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:isconcretetype)@inferredpasses for field access fromNonlinearSolver@inferredpasses through::NamedTupleannotation dispatchTesting
julia --project=. -e 'using Pkg; Pkg.test()')@inferredChangelog