performance - yuhannah/skills_map GitHub Wiki

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,也减少了很多。但是重定位的计算量和地图面积正相关,这里并没有大幅度优化空间。

(图略)