Valgrind 性能检测

准备工作

为了排除其他因素干扰，对test_rawlog和test_mclBestPose做了以下修改：

1.删除画图相关代码，保留纯算法接口（initialize和processxx）

2.代码中屏蔽SSE并行加速，实际跑机用不上

3.CMakeLists添加add_compile_options(-std=c++11 -g -Wall)

-g:调试信息

-Wall:全部警告

保持正常跑机一样的优化指令

4.存储rawlog包，确认仿真代码可以正常使用

性能优化

1.按上述准备，编译仿真代码，生成可执行文件

2.分析接口调用频率的命令：valgrind --tool=callgrind ./test

使用callgrind检测性能-slam

(1).修改前:20帧数据

==19104== 
==19104== Events    : Ir
==19104== Collected : 457732921
==19104== 
==19104== I   refs:      457,732,921

(2).修改后:20帧数据

==10608== Events    : Ir
==10608== Collected : 490788331
==10608== 
==10608== I   refs:      490,788,331

结论：当前的修改并没有针对性能进行优化，所以数据看不出差别。我也不知道这些数据表示什么，主要看KCachegrind可视软件给出的图表进行分析。

用KCachegrind可视软件打开callgrind.out.xxx文件，得到如下图表：

修改前：能看出跑19帧数据，1帧用于初始化，18帧用于迭代，图中processActionObservation()旁边的18 x表示接口调用18次。接口旁边的数字表示接口调用次数，体现了调用热度。将调用最频繁的接口进行优化（简化计算量），能够大幅度降低CPU占用。图中显示了调用最多的接口是kdTreeClosestPoint2D()。

（图略）

修改后：差别不大，在slam的计算量方面很难优化了。

（图略）

使用callgrind检测性能-mcl

(1).修改前：5帧数据call

==19124== 
==19124== Events    : Ir
==19124== Collected : 936106925
==19124== 
==19124== I   refs:      936,106,925

(2).修改后:5帧数据call

==10656== Events    : Ir
==10656== Collected : 306122953
==10656== 
==10656== I   refs:      306,122,953

结论：主要看KCachegrind可视软件给出的图表进行分析。

用KCachegrind可视软件打开callgrind.out.xxx文件，得到如下图表： 修改前：能看出跑5帧数据，1帧用于初始化，4帧用于迭代，图中processRL()旁边的4 x表示接口调用4次。图中显示了调用最多的接口是kdTreeClosestPoint2D()。

（图略）

修改后：kdTreeClosestPoint2D()的调用次数从42876->6894，减少了很多。computeLikelihoodField_Thrun()的调用次数从7550->2050，也减少了很多。但是重定位的计算量和地图面积正相关，这里并没有大幅度优化空间。

（图略）