Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

yarp::os::ThreadStats #1230

Closed
wants to merge 3 commits into from
Closed

Conversation

diegoferigo
Copy link
Member

Referring to #1207, these ThreadStats and MultipleThreadStats classes allow the computation of statistics on threads / periodic functions.

ThreadStats is API compatible with the current yarp::os::RateThreadCallbackAdapter class. I successfully validated and compared the methods. The main difference is the function I use to calculate the variance, but no significative differences emerged.

Beyond the possible usage inside RateThread, these classes might be very useful to debug issues like #1229, especially the MultipleThreadStats. I developed this class having in mind a clean and easy setup of many profiling points in a whole class codebase.

[WIP] I still have minor edits I'd like the last version will implements. For the time being, please let me know if you have any feedback about the current status.

(I'd prefer keeping this out of the next yarp master freeze for the time being)

// Advanced statistics: histogram
// ==============================
unsigned bins_pitch_ms;
std::map<unsigned, unsigned> jitter_pdf;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sure this list is allocated before the thread starts running and deallocated after the thread stopped. If you modify the size of the list dynamically during the thread execution there may be a performance hit.

Copy link
Member Author

@diegoferigo diegoferigo May 26, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

jitter_pdf entries are correctly allocated (twice, I just noticed) in _initializeJitterPDF() and _resetStats(). The dynamic allocation happens inside the map class, and since I didn't use any pointers, all the resources should be correctly deallocated when the thread is stopped.

@diegoferigo diegoferigo force-pushed the ThreadStats branch 2 times, most recently from e3ac81e to 48b9b85 Compare May 26, 2017 11:31
@Nicogene Nicogene added the PR Status: Changelog - Not OK This PR does not have a changelog entry, or the changelog needs to be fixed label Jun 21, 2017
@drdanz
Copy link
Member

drdanz commented Oct 11, 2017

@diegoferigo Is this PR finished or abandoned? If it is finished, can you rebase it and remove the WIP from the title?

@barbalberto
Copy link
Collaborator

If I remember corectly, @diegoferigo was waiting for the clock refactoring to be completed before merging this PR to avoid too many comflicts.

The refactored clock is in devel from a couple of months now, so I think now is a good time to add this feature.
Please @diegoferigo take a look if something has to be updated due to the changes I did.

@diegoferigo
Copy link
Member Author

@drdanz
The situation is exactly as @barbalberto explained. I'd like to test the RateThread code I have somewhere (after rebasing it on the new clock code) that uses this ThreadStats class instead of the current methods for statistics and push them together.

@drdanz
Copy link
Member

drdanz commented Oct 13, 2017

Should we defer it to the next release then? We are releasing on the 23rd...

@diegoferigo
Copy link
Member Author

diegoferigo commented Oct 25, 2017

I thought I had already replied to this message. Yes, I need further testing before hitting master.

@drdanz drdanz added the PR Status: Rebase - Not OK This PR needs to be rebased over the latest commit in the target branch label Nov 27, 2017
Copy link
Member

@Nicogene Nicogene left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After a quick glance it seems a nice patch!
I would add some doxygen documentation for the public API and a ThreadStatsTest to harness_os for testing the basic functionalities.
BTW nice work @diegoferigo 👍

@pattacini pattacini removed their request for review December 18, 2017 18:47
@drdanz drdanz added PR Status: Changelog - OK This PR has a proper changelog entry PR Status: Copyright - Not OK Files in this PR have copyright issues and removed PR Status: Changelog - Not OK This PR does not have a changelog entry, or the changelog needs to be fixed labels Mar 12, 2018

/*
Consider:
* |---------| Thread's or DUT's period
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Device Under Testing (DUT)


// Constant values
// ===============
double m_window_length; // Lenght of the window for calculating statistic features
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Length

@diegoferigo
Copy link
Member Author

@drdanz Ready to go as soon as all checks succeed.

Copy link
Member

@drdanz drdanz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few other comments:

namespace os {
class ThreadStats;
class MultipleThreadStats;
const unsigned WINDOW_LENGTH_DEFAULT = 60;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These constants should not pollute the yarp::os namespace, perhaps they should be class members?
Also will it work with constexpr instead of const?

*/

#include <yarp/os/LockGuard.h>
#include <yarp/os/ThreadStats.h>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ThreadStats.h should be the first include in the file ThreadStats.cpp. In this way you implicitly test that your .h file contains all includes and the definitions required

@@ -62,6 +62,11 @@ Important Changes
New Features
------------

#### `YARP OS`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The YARP_OS section should be under the Libraries section

* BSD-3-Clause license. See the accompanying LICENSE file for details.
*/

#ifndef YARP_THREAD_STATS_H
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be YARP_OS_THREADSTATS_H

@drdanz
Copy link
Member

drdanz commented Oct 3, 2018

@diegoferigo we should decide what to do with this PR. Honestly I haven't merged it yet because I cannot figure out how to use it, it would be great if you could rebase the PR and add at least some example...

@drdanz
Copy link
Member

drdanz commented Oct 7, 2019

Closing for now, please reopen if you would like to add some docs or example.

@drdanz drdanz closed this Oct 7, 2019
@diegoferigo
Copy link
Member Author

@drdanz Yes sorry but I didn't find enough time to clean this up.

Anyway, if we ever want to add profiling support to YARP, I would go towards solutions like Celtoys/Remotery. It is way more complete than what I implemented in this PR and it allows visualizing the report in the browser 😍

It is used under the hood by Ignition Gazebo. I really like how they implemented because is very compact and uses RAII to scope the profiled section.

Resources:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Library - YARP_os PR Status: Changelog - OK This PR has a proper changelog entry PR Status: Copyright - Not OK Files in this PR have copyright issues PR Status: Rebase - Not OK This PR needs to be rebased over the latest commit in the target branch PR Type: Feat/Enh This PR adds some new feature or enhances some part of YARP Resolution: No Feedback Received
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants