[maemo-developers] Profiling on Nokia N810

From: Eero Tamminen eero.tamminen at nokia.com
Date: Fri Sep 5 15:21:43 EEST 2008
Hi,

ext Bruno wrote:
>  I've been trying to profile my program on the nokia N810 for some
>  times now, and I'm not able to get good results. I installed the
>  oprofile package and the oprofile modified kernel, and then tried to
>  run gprof.
> 
>  I tried 2 ways to get my profiling information (my program is called
>  src ... not really explicit I know ! ) :
> 
>  compile with normal compiler paramaters, no -pg. Then :
> 
>  Nokia-N810:~# opcontrol --init
>  Nokia-N810:~# opcontrol --no-vmlinux
>  Nokia-N810:~# opcontrol -e=CPU_CYCLES:100000
>  Nokia-N810:~# opcontrol --start
>  Nokia-N810:~# ./src
>  Nokia-N810:~# opcontrol --stop
>  Nokia-N810:~# opgprof src
>  Nokia-N810:~# gprof src > lala.txt
>  gprof: gmon.out is file is missing call-graph data
>  Nokia-N810:~# gprof -Q src > lala.txt

Why not just use "opreport" like suggested in the documentation:
	http://maemo.org/development/tools/doc/diablo/oprofile/
?

FYI: if I want callgraphs, I'll profile on x86 with Valgrind+callgrind
(in Scratchbox) and view the results with Kcachegring (outside
Scratchbox).  Callgrind gives *much* better callgraphs and UI/usability
than oprofile or gprof.

This of course assumes that your source code works the same on ARM
and x86.


Summary:
- Oprofile for finding ARM bottleneck functions
- Timings code to measure the performance on ARM (profiling disturbs
   the code functionality so it's not to be trusted too much)
- Valgrind/Callgrind/Kcachegrind on x86 to _analyze_ the bottlenecks
   (why/how the bottlenecks are used by the running code)

I've found that x86 profiling results are mostly accurate even for
ARM, it's rare for major bottlenecks to differ between these two
architectures (although that may happen due to cache size
differencies and VFP vs. FPU) if you've otherwise guaranteed
that the execution environments match.


	- Eero

More information about the maemo-developers mailing list