Re: [eigen] Pre-allocating LU objects

[ Thread Index | Date Index | More 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
To: <eigen@xxxxxxxxxxxxxxxxxxx>
Subject: [eigen] Pre-allocating LU objects


I am writing code where I am pre-allocating a bunch of Eigen3 objects and reusing them O(10^5) times in my simulation. Therefore, I am trying to push as much as possible of the memory allocation to the sim initialization before
the main loop.

FullPivLU and PartialPivLu don't seem to have constructors that just resize them initially. They seem to get resized only when a matrix is passed as CTOR argument or when the compute() method is called. My sim uses the default CTOR
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 Eigen code does this too. So the first call to ??PivLU::compute() in my code should
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 performance hit due to invasive scratch-memory allocation in ??PivLU should therefore be

  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 use
at instantiation?


Mail converted by MHonArc 2.6.19+