|Re: [eigen] Pre-allocating LU objects|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
As far as I know, there is already a constructor of MatrixPivLU that takes 2
ints. However I don't know if it does allocate a matrix...
MatrixPivLu::Compute(matrix) does copy your matrix in its m_lu member before
doing any computation, performance may suffer. I suggest you use the lower
level makeluinplace() method if performance is critical in your application.
From: "Manoj Rajagopalan" <rmanoj@xxxxxxxxx>
Sent: Friday, May 21, 2010 6:46 PM
Subject: [eigen] Pre-allocating LU objects
I am writing code where I am pre-allocating a bunch of Eigen3 objects
reusing them O(10^5) times in my simulation. Therefore, I am trying to
as much as possible of the memory allocation to the sim initialization
the main loop.
FullPivLU and PartialPivLu don't seem to have constructors that just
them initially. They seem to get resized only when a matrix is passed as
argument or when the compute() method is called. My sim uses the default
and calls compute() later with the matrix to be factorized but the size of
the matrix is the same throughout.
Most resize methods check the provided sizes against the currently
allocated size before actually performing the new and I am guessing
code does this too. So the first call to ??PivLU::compute() in my code
cause allocation and the rest of them should be no-ops because I am always
solving the same-size matrix. Am I right in concluding that the
hit due to invasive scratch-memory allocation in ??PivLU should therefore
Will it be a good idea to include a CTOR that takes only size arguments
(dynamic, not static) and allocates the scratch memory that these classes