SciML / SciML/SparseWithDenseRowColMatrices.jl
Precompile workload covers only the LU path — none of the QR / lstsq / adjoint surface is precompiled
Nobody has claimed this yet.
- Dominant language
- Julia
- Stars
- 0
- Forks
- 1
- Avg merge
- 14m
- Merged PRs (30d)
- 6
Description
WHAT: The @compile_workload (src/SparseWithDenseRowColMatrices.jl:37-53) exercises only A*b, factorize(A), F\b, refactor!(F, nonzeros(...)) — all LU/Woodbury. It never touches qr, QR refactor!/ldiv!, adjoint/transpose matvec (A'*u), or lstsq/SparseWithDenseRowColLeastSquares. WHY IT MATTERS: The entire new feature surface — the point of this work — pays full first-call compilation latency, directly undercutting the new features' UX. PrecompileTools is already set up, so extending is cheap. FIX: In the existing for T in (Float64, ComplexF64) loop add Fq = qr(A); Fq \ b; refactor!(Fq, A); Fq' \ b; A' * b; lstsq(A2, b) (small well-posed A2, guard the lstsq call). Keep it small (current workload uses n=12, r=2). EFFORT: S.
Priority: medium. Filed from an automated next-steps audit of the QR/lstsq work (see PR #6).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in src/SparseWithDenseRowColMatrices.jl:37-53 and inspect the existing PrecompileTools workload inside the Float64 and ComplexF64 loop. Extend the workload to cover the named QR, adjoint/transpose matvec, and lstsq paths using the small dimensions described, then verify that the package's precompile workload completes successfully.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia
- Domain
- performance
- Issue type
- Feature
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 75/100