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:49] 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. |