fpco / ghc-prof-flamegraph

ghc-prof-flamegraph

This is a small tool to convert GHC time profiling reports into a format understandable by the FlameGraph tool.

Install

cabal install

Usage

First convert a .prof file into the flame graph svg:

$ cat ~/src/packdeps/packdeps.prof | ghc-prof-flamegraph > packdeps.prof.svg

Or, alternatively, just pass the .prof file as an argument. The tool will then create corresponing .svg file:

$ ghc-prof-flamegraph ~/src/packdeps/packdeps.prof
Output written to ~/src/packdeps/packdeps.svg

The previous command will produce ~/src/packdeps/packdeps.svg file.

You can customize the behavior of the underlying flamegraph.pl by passing options via –framegraph-option. For example, you can customize the title:

$ ghc-prof-flamegraph ~/src/packdeps/packdeps.prof '--flamegraph-option=--title=Package dependencies'
Output written to ~/src/packdeps/packdeps.svg

You can also generate a flamegraph using the allocation measurements, using the --alloc flag.

ghc-prof-flamegraph's Issues

number of samples (shown in mouse-overs) is not number of ticks

For the full graph (the full bar at the bottom), it says "1,000 samples, 100%", and for inner nodes, it says, e.g., "86 samples, 8.60%". I think that percentage is correct but "number of samples" is always 10 times percentage. I was expecting the number of ticks in the profile to be shown.

It does not matter much, but it had me confused for a moment because I thought "oh, that number of samples is much too low, need to re-run with different parameters" - until I remembered that the run did indeed take one hour.

(example https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/issues/850#note_35254 )

update description in the .cabal file

The description on hackage still states that the output should be postprocessed using flamegraph.pl which is no more true. Instead of maintaining two examples of use, you might want to link it instead to this README.

btw thank you a lot for your work, it has saved me plenty of time :)

change travis setup to use stack

Right now ghc-prof-flamegraph travis setup uses cabal and not stack. Is it ok to change to stack? There is already a stack.yaml in the repository but it's not used in the test.

ghc-prof-flamegraph/.travis.yml

Lines 4 to 5 in f1d7bfc

	- CABALVER=1.18 GHCVER=7.8.4
	- CABALVER=1.22 GHCVER=7.10.1

ghc-prof-flamegraph/stack.yaml

Line 5 in f1d7bfc

resolver: lts-7.15

I don't know how to setup travis configuration, i might look into it later. If someone else knows how to do this feel free to pick this up.

Stack warning about exposed-modules

during stack build

Warning: The following modules should be added to exposed-modules or other-modules in /home/flip111/ghc-prof-flamegraph/ghc-prof-flamegraph.cabal:
    - In ghc-prof-flamegraph component:
        ProfFile

Missing modules in the cabal file are likely to cause undefined reference errors from the linker, along with other problems.

large UNKNOWN frame

Piping my profiling information through ghc-prof-flamegraph, the UNKNOWN frame takes up 40% of the runtime in the resulting flamegraph. What does that mean? I looked at the code but I don't understand why it's doing what it does.

problems parsing prof file

old way of doing things

» cat wai-test.prof | ghc-prof-flamegraph > wai-test.folded
ghc-prof-flamegraph: Malformed .prof file: couldn't find start line
CallStack (from HasCallStack):
  error, called at ghc-prof-flamegraph.hs:29:17 in main:Main

new way

» ghc-prof-flamegraph wai-test.prof

Just gets stuck .. doesn't terminate

for prof file see attachment
wai-test.prof.txt

ghc-prof-flamegraph was build with lts-9.18

Feature request: flamegraph of memory usage

With the ghc rts -pa flag also information about memory is available. Other tools like profiteur can also show memory usage. Would be good if flamegraph can show memory usage too.

New release?

Bunch of new changes in master and last release was in 2015. Would now be a good time for a new one?

GHC 8.0.2 changes the profiling format

The profiling format has changed with GHC 8.0.2 which breaks the parser.
The differences are described in the commit messages https://git.haskell.org/ghc.git/commitdiff/d7933cbc28f4f094eba3d128bc147920f68c965b.
I’m not sure when I’ll get around to fixing this so if somebody else wants to fix this, be my guest :)

ERROR: No stack counts found

https://gist.github.com/spearman/9a32b5463f114db7f4d62506a422c8e6

This folded .prof file results in the following error from flamegraph.pl:

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.8.4
$ cat gan.prof | ghc-prof-flamegraph > gan.prof.folded
$ cat gan.prof.folded | flamegraph.pl > gan.prof.svg
Ignored 1938 lines with invalid format
ERROR: No stack counts found

.folded files are rendered incorrectly when used with current FlameGraph tool.

Currently, when generating the .folded-file, this tool takes the inherited measure of each line in the .prof-file. With the current version of the FlameGraph tool, this results in incorrect graphs.

For example, when taking this very simple .prof file:

Fri Aug 16 19:21 2016 Time and Allocation Profiling Report  (Final)

         test +RTS -N -p -RTS

    total time  =       47.77 secs   (47771 ticks @ 1000 us, 1 processor)
    total alloc = 58,562,517,432 bytes  (excludes profiling overheads)

COST CENTRE                    MODULE      %time %alloc

foo                            Main         66.7   66.7
bar                            Main         33.3   33.3


                                               individual     inherited
COST CENTRE      MODULE      no.     entries  %time %alloc   %time %alloc

MAIN             MAIN         300           0    0.0    0.0   100.0  100.0
 main            Main         601           0    0.0    0.0   100.0  100.0
  foo            Main        1258        6666   66.7   66.7    66.7   66.7
  bar            Main        1258        3334   33.3   33.3    33.3   33.3

We can see that main has no individual work, and foo and bar is where all the CPU time is spent.
However, when rendering the graph with the current version of FlameGraph, the following happens:

Instead, I would expect to see this:

I will open a PR with the fix.