Profile and reduce simulation overhead #366
Description
Opening an issue to start to collect some measurements in terms of possible causes of inefficiency in the sim (esp. on our end with ROS interface things).
Here is a callgrind file from a sim run; view with e.g. KCacheGrind.
Some observations so far (preliminary, and not totally confident... this code includes lots of cycles that confuse the profiler...)
- MBP simulation itself seems to take a majority (but not a huge majority) of the time, but with more cameras, rendering might take the lead.
- The slowest part of the RosRgbdCameraPublisher is its loop copying the depth image into the ROS message, but it takes about 1/5 the time as the rendering itself. (So there's lots room for improvement, especially as it's a relatively straightforward simple memory copy, but it's not egregious as we worried.)
- The RViz Scene Graph viz is definitely doing something bad -- the IM ApplyChanges() method is taking something like 5% of all runtime, and seems to be on the same order of magnitude (maybe 2x-4x less?) than the RGBD rendering.
But again these are viewed through the lens of profiling code that gets called from a really complicated cyclic call graph (I think, since the systems framework does many evaluations on-demand by dependency tracking, e.g. so the RGBD camera publisher system actually gets "credit" for the RGBD rendering). I'll poke a bit more at doing this profiling in other ways (via abalation, and via some hooks into the System framework...)