Gmon.Out Is Not Written After Compiling with Gcc -Pg -G

Why does a variable in my program use 60% of the execution time?

when you run run a gprofiled program, it writes the data in a file, usually gmon.out. That file contains the addresses of the functions, not the names. When you read the data with the gprof utility, it resolves the names using the debugging information present in the program.

That means that if you run the program, recompile it and execute gprof without re-running the program, the output is meaningless.

What is the difference between profilers that need recompiling and those that do not?

I'm not familiar with the named profilers but there are two major approaches to profiling:

Instrumentation, this method usually requires recompiling (not always, for example java and .Net applications can be instrumented dynamically). With this method it is possible to measure exactly how often a routine is called, or how many iterations a certain loop makes.

Sampeling is a method that does not require any recompiling, it simply takes a snapshot of the stack with set intervals. This has proven to be an effective way to find bottlenecks.

There is some more info about the two strategies here

How to use gprof to profile a daemon process without terminating it gracefully?

Need to profile a daemon written in C++, gprof says it need to terminate the process to get the gmon.out.

That fits the normal practice of debugging daemon processes: provision a switch (e.g. with command line option) which would force the daemon to run in foreground.

I'm wondering anyone has ideas to get the gmon.out with ctrl-c?

I'm not aware of such options.

Though in case of gmon, call to exit() should suffice: if you for example intend to test say processing 100K messages, you can add in code a counter incremented on every processed message. When the counter exceeds the limit, simply call exit().

You also can try to add a handler for some unused signal (like SIGUSR1 or SIGUSR2) and call exit() from there. Thought I do not have personal experience and cannot be sure that gmon would work properly in the case.

I want to find out the hot spot for cpu cycle

My usual practice is to create a test application, using same source code as the daemon but different main() where I simulate precise scenario (often with a command line switch many scenarios) I need to debug or test. For the purpose, I normally create a static library containing the whole module - except the file with main() - and link the test application with the static library. (That helps keeping Makefiles tidy.)

I prefer the separate test application to hacks inside of the code since especially in case of performance testing I can sometimes bypass or reduce calls to expensive I/O (or DB accesses) which often skews the profiler's sampling and renders the output useless.

Using ofstream on AIX

It's been a while, but out of my head: don't you need to add -pthread to the compile / link options?

three out of five file streams wont open, i believe its a problem with my ifstreams

Your code works. I think your current directory is not what you think it is.

Where are these files stored? Is your current directory the Debug/Release directory where the executable is stored or something like that?

You need to call close before opening the files for writing.

Avoid using the exit(0) function, as it doesn't give the C++ runtime the chance to cleanup gracefully. Throw a std::runtime_error instead.