I am running cygwin on windows and using latest version of gprof for profiling my code. My problem is that the flat profile shows zero sec for each of the functions in my code, I even tried to loop the functions(tried a for loop for a million) but gprof is unable to accumulate any time .Please help . Here is one of my sample function.
bool is_adjacent(const char* a ,const char* b)
{
for(long long iter=0;iter<=1000000;iter++){
string line1="qwertyuiop";
string line2="asdfghjkl";
string line3="zxcvbnm";
string line4="1234567890";
int pos=line1.find(*a);
if(pos!=string::npos){
if ((line1[pos++]==*b)||((pos!=0)&&(line1[pos--]==*b)))
return true;
else return false;}
pos=line2.find(*a);
if(pos!=string::npos){
if ((line2[pos++]==*b)||((pos!=0)&&(line2[pos--]==*b)))
return true;
else return false;}
pos=line3.find(*a);
if(pos!=string::npos){
if ((line3[pos++]==*b)||((pos!=0)&&(line3[pos--]==*b)))
return true;
else return false;}
pos=line4.find(*a);
if(pos!=string::npos){
if ((line4[pos++]==*b)||((pos!=0)&&(line4[pos--]==*b)))
return true;
else return false;}
}
}
I'm having that problem from time to time. Esp. in heavily threaded code.
You can use valgrind with the --callgrind option (tool) which will allow you to at least have a more detailed view of how much time per function call. There's a kde tool as well to visualize the output (and eswp. callgraph) better called kcachegrind. Don't know if you can install that on cygwin though.
If your overall goal is to find and remove performance problems, you might consider this.
I suspect it will show that essentially 100% of the CPU time is being spent in find and string-compare, leaving almost 0% for your code. That's what happens when only the program counter is sampled.
If you sample the call stack, you will see that the lines of code that invoke find and string-compare will be displayed on the stack with a frequency equal to the time they are responsible for.
That's the glory of gprof.
P.S. You could also figure this out by single-stepping the code at the disassembly level.
What version of gprof are you using? Some old versions have this exact bug.
Run gprof --version and tell us the results.
Related
Is it possible, in any debugger for C/C++ to see where the last return statement happened? Or even a "return stack", like the call stack but the other way around?
bool foo(int bar)
{
if(bar == 1) return false;
if(bar == 2) return false;
return true;
}
void baz()
{
bool result = foo(4);
}
So after the call to foo in baz, you can see which of the three return statements in foo that was hit.
Here are some reverse debugger for C/C++ which can step back in time in your debug session:
Only Linux:
rr from mozilla
open source, really fast, small record traces, has to record the whole application
undo reverse debugger
commercial, not so fast as rr, small record traces, recording of application can start anywhere
GDB reverse debugging
standard gdb from GNU, can record small functions (limited), start debugging, set breakpoint, then start recording until next breakpoint, you can reverse debug between those points
Not tested by me:
RogueWave TotalView Debugger
commercial, comes with full IDE
Windows 10 (7 not supported)
WinGDB Reverse Debugging
not tested, cannot say much about it. It seems to be the only one working with windows
What to add, multithreading can be handled by these debuggers, but only if the execution of the threads is serialized to one core (pseudo-parallalization). You can't reverse debug multicore-multithreaded applications. The reason is simple, the reverse execution has to synchronize the executed threads, which can't be done if two or more threads are executed at the "same time".
Profiling performance of a couple functions in my C# application. I was using the .Net Stopwatch to time a function over 20,000 calls. And the timing worked out to around 2.8ms per call.
However when using dotTrace in line by line mode I find that 20,000 calls to my function takes 249,584ms which is ~12.5ms per call.
Now, the function is attached to a dispatch timer, so the Stopwatch was located inside the function and not registering the call itself. Like so:
private static Stopwatch myStop = new Stopwatch();
private MyFunction(object obj, EventArgs e)
{
myStop.Start()
//Code here
myStop.Stop();
Console.WriteLine("Time elapsed for View Update: {0}", myStop.Elapsed);
myStop.Reset();
}
However, I find it hard to believe that the call was taking 10 milliseconds on average.
Is there anything else that could be affecting the timing of the profiler or Stopwatch? Is the dispatch timer event affecting the timing that much?
I've looked through some of the JetBrains forums and wasn't able to find anything related something like this, but I'm sure I could have looked harder and will continue to do so. I do realize that the Stopwatch is unreliable in some ways, but didn't think it could be this much.
It should be noted that this is the first time I've profiled code in C# or .Net.
Short answer: line-by-line profiling have biggest overhead than any other profiling type.
For the line-by-line profiling dotTrace(and others profilers) will insert calls to some profiler's function, lets call it for example GetTime() which calculates time spent from the previous call, sums it and write somewhere in snapshot.
So your function not so fast and simple anymore.
Without profiling your code can look like this:
myStop.Start();
var i = 5;
i++;
myStop.Stop();
And if you start it under profiler it will be like this:
dotTrace.GetTime();
myStop.Start();
dotTrace.GetTime();
var i = 5;
dotTrace.GetTime();
i++;
dotTrace.GetTime();
myStop.Stop()
So 12.5 ms you get includes all this profiler API calls and distorts absolute function time alot. Line-by-line profiling mostly needed to compare relative statements times. So if you want to accurately measure absoulte function times you should use Sampling profiling type.
For more information about profiling types you can refer to dotTrace Profiling Types and comparison of profiling types help pages.
Is there any way to print to a text file the code that it's being executed for debugging purposes?
for example:
if (i == 1)
{
a = true;
}
else
{
a = false
}
So when i = 1 we print to a text file:
if (i == 1)
{
a = true;
}
else
and when i != 1 we print to the text file
if (i == 1)
else
{
a = false
}
I am not saying that this is a good practice. I know that gdb and other tools are much better to debug code so please don't get mad if you think that it's an awful idea. I was just wondering if it can be done. It would be like adding a printf after every line so we only print the lines that get executed. No thread save or anything like that.
I think what you want hasn't anything to do with debugging in the first place, but with unit testing and test coverage:
You'll need to create unit tests (e.g. using googletest) for your code and compile it with code coverage options switched on (e.g. --coverage for GCC). Then you can use a tool to create a coverage report (e.g. lcov/genhtml for the mentioned toolchain).
The unit tests will control the input for your cases (i = 1/0).
For debugging purposes I would say it is not practical. Yes, you can do a printf before/after each line of execution, but that would just clog up your program. Also, if you're talking about debugging the execution of loops, you will end up printing a bunch of junk over and over again and would have to look forever to find potential bugs. In short, use breakpoints.
However, from a theoretical standpoint, it is possible to create a program that outputs itself. This is a little different from what you want because you only need parts of your program, but my best guess is that with a little modification it can be done.
I run the following with Code::Blocks
#include <iostream>
using namespace std;
int main()
{
cout << "Hello, world !!!!!!!";
return 0;
}
Now, there were some questions last night about how I knew my return value. I don't know if it's my version or not, but after the program runs on my version it says "Process returned v (0xv) execution time..." and etc where "v" is the returned value.
Now, here is what I'm asking, and this is as clear as I can make it.
When I run this, it returns value 1993075819 instead of 0. Also, the program doesn't run, all it does is show me the returned value.
Two things worthy of note:
AVG pops up everytime I try and do this, and reports it as a trojan
If I run the code without
cout << "Hello, world!!!!";
It returns 0 like it should and AVG does not pop up
How can I fix this?
(Code::Blocks 12.11)
The problem is not with your code, but with a false positive produced by AVG. The return code 1993075819 is because AVG intercepts the program and does not let it run.
You can report the false positive to AVG. Virus vendors are actually very good at fixing false positives reported by users. When I used to work at a company that produced lots of false positives (security related code that did funky things that triggered false positives), the turn-around was usually about a week.
In the mean time, if you use different compiler switches (e.g. optimized compile if it is not currently optimized or vice versa) there's a decent chance that the code you generate will not trigger the false positive.
You can also add your compiled program to the AVG safe list:
http://www.ehow.com/how_8192066_add-exceptions-avg.html
Disable AVG or configure it not to complain about your executable. For some reason the heuristics are misinterpreting some bit pattern in your executable as if it was a trojan and killing it before it starts. The result code that you get is from the intercepted program call (i.e. the antivirus) not from your program that is not even running.
I've just been pulling my hair out trying to make Instruments cough up my deliberately constructed memory leaks. My test example looks like this:
class Leaker
{
public:
char *_array;
Leaker()
{
_array=new char[1000];
}
~Leaker()
{
}
};
void *leaker()
{
void *p=malloc(1000);
int *pa=new int[2000];
{
Leaker l;
Leaker *pl=new Leaker();
}
return p;
}
int main (int argc, char **argv)
{
for (int i=0; i<1000; ++i) {
leaker();
}
sleep(2); // Needed to give Instruments a chance to poll memory
return 0;
}
Basically Instruments never found the obvious leaks. I was going nuts as to why, but then discovered "sec Between Auto Detections" in the "Leaks Configuration" panel under the Leaks panel. I dialed it back as low as it would go, which was 1 second, and placed the sleep(2) in in my code, and voila; leaks found!
As far as I'm concerned, a leak is a leak, regardless of whether it happens 30 minutes into an app or 30 milliseconds. In my case, I stripped the test case back to the above code, but my real application is a command-line application with no UI or anything and it runs very quickly; certainly less than the default 10 second sample interval.
Ok, so I can live with a couple of seconds upon exit of my app in instrumentation mode, but what I REALLY want, is to simply have Instruments snapshot memory on exit, then do whatever it needs over time while the app is running.
So... the question is: Is there a way to make Instruments snapshot memory on exit of an application, regardless of the sampling interval?
Cheers,
Shane
Instruments, in Leaks mode can be really powerful for leak tracing, but I've found that it's more biased towards event-based GUI apps than command line programs (particularly those which exit after a short time). There used to be a CHUD API where you could programmatically control aspects of the instrumentation, but last time I tried it the frameworks were no longer provided as part of the SDK. Perhaps some of this is now replaced with Dtrace.
Also, ensure you're up to date with Xcode as there were some recent improvements in this area which might make it easier to do what you need. You could also keep the short delay before exit but make it conditional on the presence of an environment variable, and then set that environment variable in the Instruments launch properties for your app, so that running outside Instruments doesn't have the delay.
Most unit testing code executes the desired code paths and exits. Although this is perfectly normal for unit testing, it creates a problem for the leaks tool, which needs time to analyze the process memory space. To fix this problem, you should make sure your unit-testing code does not exit immediately upon completing its tests. You can do this by putting the process to sleep indefinitely instead of exiting normally.
https://developer.apple.com/library/ios/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingLeaks.html
I've just decided to leave the 2 second delay during my debug+leaking build.