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