This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
cs:profiling:start [2017/01/02 11:57] James Irwin [Notes on Optimizing Code] |
cs:profiling:start [2017/01/13 15:00] (current) Brandon Kallaher [C++] |
||
---|---|---|---|
Line 9: | Line 9: | ||
This will start up your node. Let it run for a while, then use ''rosnode kill'' to kill your node, and valgrind will dump its output to a file called ''callgrind.out.<pid>''. | This will start up your node. Let it run for a while, then use ''rosnode kill'' to kill your node, and valgrind will dump its output to a file called ''callgrind.out.<pid>''. | ||
- | Next, load up this output file with kcachgrind: | + | Next, load up this output file with kcachegrind: |
kcachegrind callgrind.out.<pid> | kcachegrind callgrind.out.<pid> | ||
===== Python ===== | ===== Python ===== | ||
- | Run your program iwth profiling turned on: | + | Run your program with profiling turned on: |
python -m cProfile -o <profile file name> <script>.py | python -m cProfile -o <profile file name> <script>.py | ||
Line 26: | Line 26: | ||
The control system is a good example here. Profiling the program at at its current state (1/2/2017) reveals that 87% of the time the control system is running its main update function which calculates what values to send to the thrusters. This is unsurprising. Within this function, 41% of the time is spent reloading the PID parameters from the parameter server, 30% of the time is spent in the r3D() function, while the remaining 29% is doing the rest of the control calculations. | The control system is a good example here. Profiling the program at at its current state (1/2/2017) reveals that 87% of the time the control system is running its main update function which calculates what values to send to the thrusters. This is unsurprising. Within this function, 41% of the time is spent reloading the PID parameters from the parameter server, 30% of the time is spent in the r3D() function, while the remaining 29% is doing the rest of the control calculations. | ||
- | Seeing this, one might think //"OMG, reloading the PID parameters every cycle is so wasteful! We should cut that out now!"//. However, it's important to keep this in perspective, the control system uses a grand total of 2.3% of my machine's computing resources. Sure, a large chunk of that 2.3% is spent reloading PID parameters, but who cares? If someday we are really strapped for CPU resources, we can modify the program to reload parameters in a timer callback (so we can have it occur less often), and then look how we can optimize the r3D() function. | + | Seeing this, one might think //"OMG, reloading the PID parameters every cycle is so wasteful! We should cut that out now!"//. However, it's important to keep this in perspective, the control system uses a grand total of 2.3% of my machine's computing resources. Sure, a large chunk of that 2.3% is spent reloading PID parameters, but who cares? If someday we are really strapped for CPU resources we can modify the program to reload parameters in a timer callback (so we can have it occur less often), and then look how we can optimize the r3D() function. |
- | Just because you can optimize doesn't mean it's worth the effort. Remember, the control system is just a drop in the bucket compared to the vision processing system. Look at overall CPU usage of a node relative to all others to determine if optimization is warranted. | + | Just because you can optimize doesn't mean it's worth the effort. Remember, the control system is just a drop in the bucket compared to the vision processing system. Look at the overall CPU usage of a node relative to all others to determine if optimization is warranted. |
+ | |||
+ | ====== Profiling Caveats ====== | ||
+ | [[http://yosefk.com/blog/how-profilers-lie-the-cases-of-gprof-and-kcachegrind.html|Here]] is a great article on how profilers can lie to us. |