最近调试S-Fast-LIO算法，包含PCL的C++ Lidar SLAM算法，编译时间总是很长难以忍受。
花了小半天，探究了下方法，并做总结。
1. Debug模式和Release模式，优化等级的影响
SET(CMAKE_BUILD_TYPE "Debug") // Release
set( CMAKE_CXX_FLAGS "-std=c++14 -O3" ) // -O3，最优化；-O0，不进行任何优化；-O1，默认，均衡优化
在代码中只修改一行，重新编译：
Debug模式，-O3优化：用时1m20s
Debug模式，-O0优化：用时1m19s（没有显著变化）
Release模式，-O0优化：50s
因此，Release模式会大大减少编译时间。
2. 使用ccache:
sudo apt install ccache
据说ccache可以在部分文件未修改的情况下提高编译速度，以空间换取时间。但我实际测试的时候，发现对于工程并不是很大、每次编译文件基本只有那么几个的，并不是非常友好。
只有当编译过这个代码，修改以后，再修改回来，会有显著的提升，但只要是有那么一丢丢的不一样，就白干。
Debug模式， -O3优化，使用ccache：
第一次编译：1 min 11s
修改1行后编译: 1min 5s
退回这次修改再编译：10.9s
3. PCL官方给出的一些注意事项
Building time of a project which depends on PCL is too long
建议：
- 如无必要，不要添加用不到的头文件；
- 多线程编译：make -jxxx
- 使用最新版的PCL可能做了优化
- 拆分多个文件，方便修改后编译更快
4. 使用 include-what-you-use 精简头文件
整理混乱的头文件，我用include what you use
安装：
- 从源码编译clang（编译很久，过程中容易爆内存，用-j1指令）：
- 安装 nuxxx，这个被IWYU依赖；
sudo apt-get install libncurses5-dev libncursesw5-dev
- 安装IWYU：
装了半天然后放弃了……编译太麻烦了，也担心把自己的系统环境搞崩，所以没有继续。
5. 分离头文件和cpp部分
由于s-fast-lio写的一言难尽，.hpp文件中包含了函数的实现，而其他文件包含该头文件时等有由包含了一次这些实现部分，因此每次修改.hpp的实现部分，都会把所有代码都编译一遍。
因此，将头文件中除了函数声明（和小的inline函数）外，全部实现放到对应的cpp文件中。重新分离出来了两个.cpp文件。此时编译时间：
修改cpp中的一样：24s
时间大大减少。
归根到底，还是官方给出的建议4：拆分多个文件，这个方式解决的问题。