2

I can use gperftools to produce a call graph, as in for instance this question.

Now I would like to get a call graph for bind_rows() in the dplyr R package in order to track down this bug.

I compiled both R and dplyr using CPP/CXXFLAGS=-g -fvar-tracking-assignments and LDFLAGS=-lprofiler -lunwind.

When I run the following:

CPUPROFILE="samples.log" R --vanilla <<< "library(dplyr)
ll = lapply(1:1e5, function(x) as.list(setNames(runif(5), letters[1:5])))
print(system.time(bind_rows(ll)))"

pprof --gif /usr/lib/R/bin/exec/R samples.log > out.gif

All I get is:

enter image description here

How can I get the call hierarchy so I know which call in dplyr's bind rows file is the bottleneck?

edit: It seems that the --focus option is what I need here. But how to connect this to RecursiveRelease?

pprof --focus=rbind__impl --gif /usr/lib/R/bin/exec/R samples.log > out.gif

enter image description here

edit: After recompiling Rcpp with -g and linking with -lprofiler, I could get the following: flame.svg, where 8% gets a good stack trace but most of it still doesn't. Could this be because some library is loaded without -lprofiler support?

Community
  • 1
  • 1
Michael Schubert
  • 2,726
  • 4
  • 27
  • 49
  • 1
    Sigh... Can you try [*this*](http://stackoverflow.com/a/378024/23771)? There's a video of it [*here*](https://www.youtube.com/watch?v=xPg3sRpdW1U). And call-graphs are a very [*porous net*](http://stackoverflow.com/a/25870103/23771). – Mike Dunlavey Oct 11 '15 at 00:28
  • Thank you for your comment. I looked at your linked answer before, but didn't quite understand how this relates to my problem (after reading it a bit more carefully I do). But surely there must be a way to automate call stack sampling using gprof/a profiler and have a graphical representation of the result? (even if it's not named "call graph", I'm not that familiar with the terminology) – Michael Schubert Oct 11 '15 at 12:41
  • 1
    First - you are doing this in order to find speedups, right? If not, ignore me. If so, understand that graphical representations only work for particular subsets of problems - not good enough. Personally examining textual stack samples finds all problems. This is not powerpoint material, it is speedup material. Another point: automating sampling 1) takes too many samples for you to examine ([*you need very few*](http://scicomp.stackexchange.com/a/2719/1262)), and 2) prevents you from taking them at the time you want, diluting the results. – Mike Dunlavey Oct 11 '15 at 13:12
  • I am just watching a video about [flame graphs](https://www.youtube.com/watch?t=53&v=nZfNehCzGdw) - can you give an example of a problem that one would see with stack samples that this misses? – Michael Schubert Oct 11 '15 at 14:33
  • Sure: [*look here*](http://stackoverflow.com/a/27867426/23771). – Mike Dunlavey Oct 11 '15 at 15:15
  • I don't know anything about R. But is it possible that R dlopens and then dlclose-s this dplyr thing? If so it might explain why profile is broken. – Aliaksei Kandratsenka Oct 11 '15 at 19:03
  • I don't think so. `dplyr` uses `Rcpp`, which when I recompiled I could get a partial good stack trace (see linked flame.svg). I assume this wouldn't happen if there was the issue you described? Could it be that it just loads other libraries that I haven't recompiled with `-lprofiler` so I don't get the proper trace? – Michael Schubert Oct 11 '15 at 21:29

0 Answers0