Re: [eigen] Pre-allocating LU objects

[Vincent Lejeune <vincent.lejeune@xxxxxxxxxx>]

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

> Hi,
>
>   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
> minimal?
>
>   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?
>
> Thanks,
> Manoj