(For MRPT 2.0) Discussion on Eigen, matrix classes and alternatives for a faster build time #496
Closed
2 tasks done
Milestone
Comments
|
Maybe something like the PCL methodology? They instantiate template types in a CPP file. They implement it in a impl header Typically you don't need the impl header(which takes the longest to compile) unless you need to instantiate versions. |
|
good! 👍 Will check if Eigen headers are already in a suitable form... |
|
I don't believe they are. This will make deriving from Eigen types almost impossible. Possibly using composition instead of derivation will be the only solution. Basically, only use Eigen in the impl header. |
|
As a reference to think about, here is the output from
It's relevant, I think, that it takes 6 s wall time to instantiate templates: Just a crazy idea: might it be useful to have Eigen refactored into declaration headers and implementation files, which might be explicitly instantiated? It might imply a small performance loss, but it should be measured to evaluate if it's acceptable. This could be a big workload on itself and no one has spare time to work on this, but... just wanted to share my thoughts! |
|
My thought was refactoring CMatrix and associated types into a c++14 implementation with allows explicit conversions to Eigen. I think this would be a good start. C++11 arrays can be stack allocated, which should improve performance. Ideally, the c++14 implementation should focus on constexpr, so that the compiler can do as many optimization as compile time as possible. http://codereview.stackexchange.com/questions/136541/simple-matrix-class-c14 |
jlblancoc
changed the title
|
mmm... it feels like rolling back the decision back taken more than 5 years ago when moving to Eigen from custom matrix classes! But it's worth considering for 2.0: it might be the simplest way of achieving small, simple templates for storing matrices, then only including That idea would work if we draw a clear border for what operations lie on "our side", with the rest being for Eigen. An idea is to just implement the most basic storage. By the way: (PS: just edited this issue title) |
|
I just realized now that my last code snippet didn't make sense, since it implies having This one should be better, as it will work only from user sources where Eigen headers are included. HEADER: SOURCE: |
|
Updated issue first comment to reflect a couple of TO-DO tasks related to this discussion. |
|
WIP for this issue is branch: matrix-hidden-eigen |
7 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tasks:
asEigen()getter.------- Original discussion --------
(cc: @jolting ) I noticed a large part of compilation time slow-down comes from the use of extensive, header-only libs, such as Eigen.
I wonder if there might exist an efficient solution that fulfills all:
#includes out of MRPT headers,Perhaps one of the value
variantcontainers may do the work?I thought of using the PIMPL idiom, then allowing users that really need to use all Eigen methods to do the #include on their side and call a templatized getter method, or something alike.
Obviously, this is not acceptable since replacing all statically allocated matrices (they are inside all CPose3D, etc. classes) with dynamic memory is a shot in the shoe!
I think it's not possible, but just wanted to start this conversation in case there is some remote possibility of doing this without a huge efficiency cost...
The text was updated successfully, but these errors were encountered: