Dynamic allocations

[ahoarau]

I'd like to integrate this library in a Xenomai setup but I'm afraid of dynamic allocations. I see some push_back in the code.
I was wondering If we could take advantage of the reserve methods for std::vector<> and eigen sparse matrices toa void any memory allocation between solver updates.

[traversaro]

@GiulioRomualdi What do you think about this? I think it is a good idea.

[S-Dafarra]

Hi @ahoarau,
with #5 and 38825e5 (and for the record 7109a22, my bad 😅 ) we have been trying to reduce memory allocation by reusing some buffers. Can you check this out? Comments are welcome 😉

[GiulioRomualdi]

Hi @ahoarau,
Remove/reduce memory allocation is, of course, a best practice, so I'll try to follow this objectivity. However, some memory allocations cannot be removed. Indeed osqp itself uses memory allocation.
For example, csc_spalloc() method allocates memory dynamically.

osqp-eigen/include/OsqpEigen/SparseMatrixHelper.tpp

Line 34 in 38825e5

osqpSparseMatrix = csc_spalloc(rows, cols, numberOfNonZeroCoeff, 1, 0);

Furthermore, every time a new optimization problem is initialized the following memory allocations are performed https://github.com/oxfordcontrol/osqp/blob/master/src/osqp.c#L111-L118

[ahoarau]

It also says that it is the only place where they perform memory allocations in the solver.
Like qpOASES, you need to setup (allocs) and then solve (no allocs).
So I believe that createOsqpSparseMatrix would only be called once before the osqp_setup function, and then all the functions called would be to update the said matrices

[NUDTUGVexplorer]

when I run the example MPCExample.cpp
it has an error: Segmentation fault (core dumped).
Then I debug the program, it shows the error in the following lines.

solver.settings()->setWarmStart(true);

how to solve the issue? Thanks a lot.

[ahoarau]

Hello @GiulioRomualdi and @traversaro , I'm back ! Was this addressed at some point ?
Can I run the solver with Eigen::internal::set_malloc_allowed(false) ?

[traversaro]

Hello @GiulioRomualdi and @traversaro , I'm back ! Was this addressed at some point ? Can I run the solver with Eigen::internal::set_malloc_allowed(false) ?

I am doing some profiling on this, and it seems that solveProblem is malloc-free, but several update*** methods are still using mallocs.