4

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.

max taldykin
  • 12,459
  • 5
  • 45
  • 64
  • Maybe [visual-prof][1] can help somehow? [1]:https://hackage.haskell.org/package/visual-prof – Vi. Nov 30 '14 at 22:57

2 Answers2

4

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.
Heatsink
  • 7,721
  • 1
  • 25
  • 36
  • All the libraries are installed with `cabal install --enable-library-profiling`. Isn't it the same as `-p -auto`? – max taldykin Mar 04 '11 at 17:24
  • No, it's the same as -p. I.e. the libraries get compiled to support the profiling calling convention, but with no cost-center annotations. I think that cabal install --enable-executable-profiling will actually pass the flags you need (despite the name), but I'm not certain off the top of my head. – Ganesh Sittampalam Mar 04 '11 at 17:45
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.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • thanks for the links. It seems that usefulness of this technique is a consequence of lack of good profiling tools (especially for ghc). – max taldykin Mar 05 '11 at 09:41