Skip to content

Reuse factor buffers across re-factorizations (follow-up to #55)#56

Merged
wo80 merged 1 commit into
wo80:masterfrom
hbadi:feature/factorize-buffer-reuse
Jun 8, 2026
Merged

Reuse factor buffers across re-factorizations (follow-up to #55)#56
wo80 merged 1 commit into
wo80:masterfrom
hbadi:feature/factorize-buffer-reuse

Conversation

@hbadi
Copy link
Copy Markdown
Contributor

@hbadi hbadi commented Jun 8, 2026

Follow-up to #55 (merged) — as you suggested, rebased onto current master for a clean history.

What

SparseLU / SparseCholesky / SparseLDL (Double and Complex) now allocate L/U
(and pinv, D) only on the first Factorize call, and Clear() + reuse the buffers
on subsequent calls (same sparsity pattern). This avoids re-allocating the factor storage
on every Refactorize — the point of #55, for Newton / time-stepping loops.

The SparseLU trim (per your note)

You suggested gating the end-of-factorization trim on AutoTrimStorage rather than dropping
it — done. SparseLU.Factorize now wraps the final Resize(0) in
if (CompressedColumnStorage<T>.AutoTrimStorage). So with AutoTrimStorage = false the
L/U buffers stay allocated across Refactorize calls → fully allocation-free reuse for
iterative solvers / time-stepping. I updated the AutoTrimStorage doc to mention this.
(Cholesky/LDL allocate the exact factor size, so no trim is involved there.)

…factorization

SparseLU / SparseCholesky / SparseLDL (Double and Complex) allocate L/U (and pinv, D)
only on the first Factorize call, and Clear() + reuse the existing buffers on
subsequent calls (same sparsity pattern), avoiding re-allocation on every Refactorize.

For SparseLU the end-of-factorization trim (Resize(0)) is now gated on the existing
CompressedColumnStorage<T>.AutoTrimStorage flag: disabling it keeps the L/U buffers
allocated across re-factorizations (iterative solvers, time-stepping) — fully
allocation-free reuse. AutoTrimStorage's doc is updated accordingly. Cholesky/LDL
allocate the exact factor size, so no trim is involved there.

Adds TestRefactorizeNoTrim (refactorize with AutoTrimStorage = false stays correct).
All 293 tests pass.
@wo80
Copy link
Copy Markdown
Owner

wo80 commented Jun 8, 2026

Thanks again, this can be merged as is!

The SparseLU implementation has quite a naive approach to memory management, just doubling the sizes of the storage arrays, in case the number of non-zeros exceed the available space. This tends to leave a lot more memory allocated than actually needed, so I added the resize-to-nonzero-count at the end of the Factorize method. Using AutoTrimStorage to opt out of the default behavior should be the right way to go.

I'll update the nuget package later this week.

@wo80 wo80 merged commit c1c7acb into wo80:master Jun 8, 2026
1 check passed
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