Add time taken metrics and a way to view them in real time

[osrf-migration]

Original report (archived issue) by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

---

Having a way to see timing information in real time will be useful for future debugging and profiling. Useful metrics are

1. How long is each system taking to update?
2. How long is it taking to update all systems?
3. How long is it taking to apply changes to the entities and components?

This kind of information would inform decisions about where time should be spent optimizing code, or where bugs might be occurring.

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

Maybe some of the diagnostics stuff from Gazebo can be reused here. I believe there is also a branch on Gazebo where this is enabled. @scpeters

[osrf-migration]

Original comment by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

---

• set assignee_account_id to "557058:684383ab-ac95-4859-a350-4a6f41a94a22"
• set assignee to "sloretz (Bitbucket: sloretz, GitHub: sloretz)"

[osrf-migration]

Original comment by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

---

Related info

• https://bitbucket.org/osrf/gazebo/branch/diagnostics_scpeters#diff
• ignition/msgs/Diagnostics
• gazebo/util/Diagnostics.hh

[osrf-migration]

Original comment by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

---

A loose port of gazebo::util::DiagnosticsManager is on the branch diagnostic_timer. The class gazebo::ecs::Manager has been modified to publish diagnostics during the two phases of Manager::UpdateSystems(). This is published to the topic diagnostics using ignition::msgs::Diagnostics.

Remaining work

• Add a way to view the metrics
• Add time information for how long individual ECS systems take (Manager will need to know the names of the systems)

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

I have two branches that I just resolved conflicts for in gazebo, though I haven't checked that they compile. The current diagnostics system lets you get timing info by placing macros throughout the code and then publishing it and writing it to a file.

• diagnostics_scpeters: this branch heavily refactors the file that is written so it only publishes statistics about the timing (mean, max-abs) instead of logging every single time. I found this much easier to parse. Here's an example of one of the files it creates:

World::Update                                     maxAbs 6.073124e-03   mean   8.419458e-04   
World::Update::ContactManager::PublishContacts    maxAbs 6.070371e-03   mean   8.404391e-04   
World::Update::LogRecordNotify                    maxAbs 6.007031e-03   mean   8.104208e-04   
World::Update::PhysicsEngine::UpdatePhysics       maxAbs 4.618062e-03   mean   7.611499e-04   
World::Update::PhysicsEngine::UpdateCollision     maxAbs 2.952573e-03   mean   1.157201e-04   
World::Update::SetWorldPose(dirtyPoses)           maxAbs 6.002424e-03   mean   8.091370e-04   
World::Update::Model::Update                      maxAbs 5.938560e-04   mean   4.594276e-05   
World::Update::Events::worldUpdateBegin           maxAbs 1.122670e-04   mean   3.632071e-06   
World::Update::needsReset                         maxAbs 5.240300e-05   mean   3.203250e-07   

• thread_diagnostics_transport_islands: I wanted to get diagnostic information about the gazebo transport system, so I removed publishing of diagnostic information from this branch. I think writing a file of statistics will have lower overhead than publishing all the data in real-time, though it isn't available in real-time.

[osrf-migration]

Original comment by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

---

• changed state from "new" to "resolved"

pull request #22 was merged