Re: [eigen] Pre-allocating LU objects

[Manoj Rajagopalan <rmanoj@xxxxxxxxx>]

I don't seem to be able to find these names in Eigen3. Were they part of 
Eigen2?

thanks,
Manoj



On Friday 21 May 2010 01:22:24 pm Vincent Lejeune wrote:
> 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