View source: R/matching_memory.R
| estimate_dense_solve_mb | R Documentation |
The matrix is the allocation a caller can reason about and it is not what bounds a dense solve. Preparation copies, the solver's own workspace and the assignment structures it carries all sit on top of the matrix, and the peak is what decides whether the solve fits, so that is the quantity the guard compares against available RAM.
estimate_dense_solve_mb(n, m, solve_factor = 12)
n, m |
Problem dimensions. |
solve_factor |
Multiplier on the raw cell bytes. |
The multiplier is read off the measurement rather than from an enumeration of the copies, which has proved to understate it. On the memory benchmark – one fresh R session per arm, peak resident set taken from outside and read against an idle session that loaded the same packages – a dense one-to-one solve peaked at 10.5, 7.2 and 8.8 times the raw matrix bytes at 5,000, 10,000 and 20,000 units. The default covers the worst of those with headroom, which is the direction a guard should err in: it exists to refuse a solve that will not fit, not to predict where the peak lands.
Numeric scalar, the estimated peak footprint of a dense solve in megabytes.
estimate_dense_solve_mb(5000, 5000)
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.