Better control about what should be profiled

[monsdar]

The user should have some sort of control about what should be profiled and what not.

My first idea is that there could be some sort of categories where Plots and Activities are under. It then is controllable via config/API/server which categories are profiled and which are ignored.

Another good concept could be the same as in most Logging Frameworks: There could be different levels like DEBUG, INFO, WARN, ... which generate different amounts of Data. It should also be possible to change the level during runtime.

[monsdar]

Is this really needed? Or does this simply involve overhead which costs performance and is not used at all. What do the end-users do:

• Create specific activities, marks and plots for a single testcase they want to perform
• Add general activities, marks and plots to everywhere where it is useful and activate those that are needed for a specific testcase

[wizfromoz]

I am reviewing CxxProf at the moment and this is one of the features we sorely would need. I'd like to be able to switch on/off tracking of any item (activity,mark or plot) at run-time. Our use case is that there are circumstances at run-time, which we can easily identify, where we want to INCREASE what we log, or specifically select/deselect.

Having levels like DEBUG, INFO, etc is a good thing, but it's a blunt instrument. We want to switch on/off specific parts. Something where you'd extend existing macros to include a predicate parameter and in there the user specifies expression that will determine whether the log would be created or not.

[monsdar]

The easiest solution would be to implement some macros like ENABLE_CXXPROF or DISABLE_CXXPROF. Then the user could control himself if he wants to profile.

A finer method could be to let the user define specific categories like CXXPROF_ACTIVITY("MyActivity", "MyCategory"). There then would be macros to dis/enable certain categories with CXXPROF_ENABLE_CATEGORY("MyCategory"). Only the enabled categories would be profiled. This adds some overhead, as it is needed to check if the current category should be profiled.

Last but not least it could be possible to create Categories specifically and give a callback for them. The callback would be a function which determines whether the category should be used or not:

bool myCallback()
{
    return false;
}

int main()
{
    CXXPROF_CATEGORY("MyCategory", &myCallback);
    CXXPROF_ACTIVITY("MyActivity", "MyCategory");
    return 0;
}

The above code is just to show you what I'm up to. Due to boost::function and boost::bind it would be possible to use class methods as callbacks too. This method obviously adds the biggest overhead, as a user function needs to be called. These could be as complex as the user wants them to be.

What do you think of these solutions? Or are there any better ways you can imagine?

[wizfromoz]

Hi Nils,

The key requirement is that the selection can be done AT RUN-TIME. That’s why macro solutions are not good, as they determine this at compile time.

Your callback idea would improve it, I guess, to some extent. However, I think that the most flexible approach would be to have a macro that accepts an additional parameter, a Boolean expression, that would determine whether the performance event would be generated or not. In there I can go from as simple as testing a global Boolean variable all the way to very complex Boolean expressions that include function calls, etc. Something like:

CXXPROF_ACTIVITY_COND( logImageRendering && loadLevel > 0.7, “Frame render”)

Regards,

Milan

[monsdar]

The macros are just there to be able to remove CxxProf-code via preprocessor-define USECXXPROF. The categories would still be evaluated at runtime. It however would add some overhead, so I think it's not the best idea.

The callback-solution is a bit oversized too, it also will be the case that there then is code which won't get removed via preprocessor-define USECXXPROF.

I think the solution where the condition is directly written into the macro-arguments is the most flexible, I'll see how it could be implemented.

[monsdar]

Just implemented this in Revision 154 - f3e0166137258bf6e04829047dc0fa853aa253be.

There are now macros called

• CXXPROF_ACTIVITY_COND(NAME, COND)
• CXXPROF_MARK_COND(NAME, COND)
• CXXPROF_PLOT_COND(NAME, VALUE, COND)

Where COND is a boolean expression. If USECXXPROF is not defined, the macro will be empty and so the expression won't get evaluated. So you're not adding any overhead to the actual implementation, if CxxProf is not active.

I still need to update the documentation, but for now I'm closing here. Just reopen the issue if there is something left behind.

[wizfromoz]

Thank you Nils, I’ll try this tomorrow (Australia time), I’ve been away for training the whole day today.

[monsdar]

Just a quick note: If you answer on Github-Issues via Email, it adds your companies "legal notice" as well as the whole conversation. Probably not what you want to do. I removed it manually from your last 3 comments.

[wizfromoz]

Sorry about that. I wasn't aware those legal notices were appended. I only recently started in this company.