How to force ghc's profiler to step deeper into the libraries?

Question

I'm trying to profile my program. So I compile it with -prof and -auto-all flags and run with -P to get detailed profiling report:

$ ghc --make -prof -auto-all Test.hs
$ ./Test +RTS -P

Here is a piece of profiling report:

COST CENTRE              MODULE  no.    entries  %time %alloc

  main                   Main   266           1   0.0    0.0
   run                   Main   273       21845  99.3   99.7
    sz                   Main   274       21844   0.0    0.0
   size                  Main   268       21845   0.7    0.3

It seems that run consumes all time and memory. It calls a lot of functions from various libraries, and I'm quite sure that most time is spent in one of them, but I can't figure in which one. How can I get more detailed report? I hope that putting lots of SCC annotations manually is not the only way.

Update. For now I "solved" the problem by copying sources of libraries to my program directory. This allows GHC to treat them as part of program, not as external libraries.

Answer 1

It's a gprof-type profiler - pretty weak, for these reasons.

You can use GHCi to find performance issues the same way you would find infinite loops, by this technique in this manner:

6.3 Infinite loops On glasgow-haskell-users on 21 Nov 2007, pepe made the following suggestion for detecting the cause infinite loops in GHCi. Assuming the offending function is named loop, and takes one argument:

1.enable the flag -fbreak-on-error (:set -fbreak-on-error in GHCi)

2.run your expression with :trace (:trace loop 'a')

3.hit Ctrl-C while your program is stuck in the loop to have the debugger break in the loop

4.use :history and :back to find out where the loop is located and why.

The only difference between any performance problem and an infinite loop is - infinite loops waste 100% of the time, while performance problems waste a lesser percent. So you might have to break into it a few times.

Answer 2

For the profiler to discriminate library functions, there have to be cost-center annotations on them. You can do this two ways:

1. Recompile the libraries of interest with -p -auto so that library functions get annotated with SCCs.
2. Insert SCC annotations around probable time-consuming library calls in your code.