Sparse factor codes can affect runtime and memory usage because they are interpreted as dense indices:
|
n_levels: max as usize + 1, |
See here for a reprex. On current main, relabelling three 100-level factors with a gap of 10,000 increases n_dofs from 300 to 2,970,003 and slows an otherwise identical persistent solve by approximately 6×.
Separately but somewhat relatedly: While rebasing I noticed your dense versus sparse sorting introduced in #221. My current implementation doesn't take advantage of it singleton detection but the issue applies more generally across the codebase which I believe is currently not addressed consistently, for example for the coefficient field SolveResult::x. I'm wondering if we should think about a compactification of sparse factor codes? (Maybe best to do open a separate issue to avoid cluttering this PR?)
Originally posted by @leostimpfle in #214 (comment)
Sparse factor codes can affect runtime and memory usage because they are interpreted as dense indices:
within/crates/within/src/domain.rs
Line 211 in 68e907f
See here for a reprex. On current main, relabelling three 100-level factors with a gap of 10,000 increases
n_dofsfrom 300 to 2,970,003 and slows an otherwise identical persistent solve by approximately 6×.Separately but somewhat relatedly: While rebasing I noticed your dense versus sparse sorting introduced in #221. My current implementation doesn't take advantage of it singleton detection but the issue applies more generally across the codebase which I believe is currently not addressed consistently, for example for the coefficient field
SolveResult::x. I'm wondering if we should think about a compactification of sparse factor codes? (Maybe best to do open a separate issue to avoid cluttering this PR?)Originally posted by @leostimpfle in #214 (comment)