Open kunaltyagi opened 4 years ago
Marking this as stale due to 30 days of inactivity. It will be closed in 7 days if no further activity occurs.
The heaviest TU obviously is the MovingLeastSquares, implemented in surface/impl/mls.hpp
.
The cost is caused by instantiating the template for the cartesian product of point types, which is 15² = 225
instantiations (or at least 6^2 = 36
for the CORE_XYZ types).
The largest method therein is computeMLSPointNormal
. But that actually does not have to be templated on the output type, as it only outputs (a cloud of) XYZ coordinates. Converting the points to the output type can happen immediately after, while appending them to the output PointCloud.
@StefanBruens Thanks for investigating! Are you interested to open a pull request with a solution? Then we can discuss this further. It would be important to verify with a measurement that this modification does not make the method/function significantly slower (run time), and that the compile time is actually reduced.
Another thing we could check is whether really all ~255~ 225 instantiation combinations are needed. For example, MovingLeastSquares<pcl::PointWithRange, pcl::PointDEM>
is probably used so rarely that instantiating it every time the library is built is not justified.
I'm one of the Conan Center maintainers. We've had requests to add and build binaries for PCL in Conan Center, and we are having issues due to compiler crashes that appear to affect the compilation of src/surface/src/mls.cpp
, which I would suspect is where mls.hpp
- PCL would require more resources than the vast majority of other things we build and package.
We'll keep an eye on this issue as well :)
@StefanBruens Thanks for investigating! Are you interested to open a pull request with a solution? Then we can discuss this further. It would be important to verify with a measurement that this modification does not make the method/function significantly slower (run time), and that the compile time is actually reduced.
Another thing we could check is whether really all 255 instantiation combinations are needed. For example,
MovingLeastSquares<pcl::PointWithRange, pcl::PointDEM>
is probably used so rarely that instantiating it every time the library is built is not justified.
I had started refactoring the code, but unfortunately I haven't completed it until now, as there are quite some cross-function dependencies. Not sure when I have time to do some more work on this, sorry.
@StefanBruens @jcar87 I created a PR to drastically reduce the number of template instantiations in MLS (by removing instantiations which are likely used by nobody). Feel free to take a look. In the future, further refactoring MLS is still possible if needed (to reduce the amount of resources needed per template instantiation).
Starting point for people who want to help optimize PCL compile times
Your Environment
Context
It might be possible to make PCL compiles faster and lighter by utilizing time-tracing utilities provided by clang-9.
Code to Reproduce
Warning: Please have plenty of spare disk space ready. Also, don't use
-Werror
-DCMAKE_CXX_FLAG='-ftime-trace'
and tests switched offClangBuildAnalyzer --start ./
ClangBuildAnalyzer --stop ./ data.json
ClangBuildAnalyzer --analyze data.json
find -name '*.json' -exec cp --parents {} <NEW_DIRECTORY_OUTSIDE_CURRENT_DIR> \;
I got a 2.4 GB tar of the json files only. (Technically you should only need the 1.2 GB data.json, but some "editors" can't edit such huge files)
Time to dig into the flamegraph (using
chrome://tracing
orhttps://www.speedscope.app/
)Synopsis