map<string,pair<__int64,int> > CallData;
class ASMTimer
{
public:
ASMTimer(string &name) : Name(name)
{
++CallData[Name].second;
Start=__rdtsc();
}
~ASMTimer()
{
End=__rdtsc();
CallData[Name].first+=End-Start;
}
private:
unsigned __int64 Start,End;
string Name;
};
class::method()
{
ASMTimer Timer("Class::Method");
...
}
Quote:Original post by Anonymous Poster
2. the "problem" with release builds is that the compiler is very likely to optimize away unused paths of your code: your profiler won't be able to collect any samples at all. you need to make sure you don't have "artificial" applications that don#t actually use the code in your libraries/objects.. simple example: if you don't use the return value of an intensive computation the compiler is free to optimize away the call to this function. The result is that the function doesn't execute, samples aren't collected.
Quote:Original post by JasonBlochowiakI already had debug information enabled in my release build. It saw one call into my class and then all the calls within the class were missed out. I don't know why!
As to the OP - yes, simple manual profiling like what you posted can be very useful. However, it's not a substitue for "real" profiling, it's an additional data point.
You may be able to use profiling on your release build if you enable the storing of debug information - how to do that varies by compiler & version.
Quote:Original post by JasonBlochowiakQuote:Original post by Anonymous Poster
2. the "problem" with release builds is that the compiler is very likely to optimize away unused paths of your code: your profiler won't be able to collect any samples at all. you need to make sure you don't have "artificial" applications that don#t actually use the code in your libraries/objects.. simple example: if you don't use the return value of an intensive computation the compiler is free to optimize away the call to this function. The result is that the function doesn't execute, samples aren't collected.
I have no idea what this person is talking about, but please ignore the post. The whole point of actually profiling an optimized build is to determine what's actually being executed.
Quote:Original post by KylotanQuote:Original post by JasonBlochowiakQuote:Original post by Anonymous Poster
2. the "problem" with release builds is that the compiler is very likely to optimize away unused paths of your code: your profiler won't be able to collect any samples at all. you need to make sure you don't have "artificial" applications that don#t actually use the code in your libraries/objects.. simple example: if you don't use the return value of an intensive computation the compiler is free to optimize away the call to this function. The result is that the function doesn't execute, samples aren't collected.
I have no idea what this person is talking about, but please ignore the post. The whole point of actually profiling an optimized build is to determine what's actually being executed.
He's actually making a valid point. If you try profiling a piece of code that, for example, just tests merging two structures together and then discarding the merged result, the compiler may well remove all that code entirely, seeing that it has no effect on the rest of the program. So in release mode it is best to profile your proper code, not artificial test cases that may get optimised away.
