  This paper focuses on the explanation of the architecture of profilers
particularly gprof and how to profile a program according to the user defined
input of execution time . Gprof is a profiler available open source in the
package of binutils. Gprof records the flow of the program including the callee
and caller information and their respective execution time. This information is
represented in the form of a call graph. Profilers at the time of execution
creates a call graph file which indicates the full flow of the program
including the individual execution time as well. This paper aims at providing a
better understanding of the data structure used to store the information and
how is a profiler(gprof) actually using this data structure to give user a
readable format. The next section of this paper solves one of the limitation of
gprof i.e. edit the time of block of code without understanding the call graph.
Any changes in the execution time of a particular block of code would affect
the total execution time. So if we edit the gprof in such a way that its
consistent and platform independent, then it can yield various results like
testing execution time after parallelism, before even designing it by replacing
the values with theoretical/emulated ones and see if the total execution time
is getting reduced by a desired number or not? Gprof edit can help us figure
out that what section of code can be parallelized or which part of code is
taking the most time and which call or part can be changed to reduce the
execution time. The last section of the paper walks through the application of
gprof in minisat and how gprof helps in the hardware acceleration in minisat by
suggesting which part to be parallelised and how does it affect the total
percentage.
