qchbai / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

divide call graphs to unconnected branch by threads #402

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

What is the expected output? What do you see instead?
Does gperftools support to divide call graphs by threads? 

e.g., a function foo() is called in multiple threads, currently gperftools will 
output one single node sums all samples of foo() in different threads. 

Is it possible to output different nodes of foo() for each thread? i.e., if 
there are 8 threads, 8 unconnected call graphs will be generated, with each 
graph representing the profiling result for each thread. 

What version of the product are you using? On what operating system?

Please provide any additional information below.

Original issue reported on code.google.com by huas...@gmail.com on 2 Feb 2012 at 1:58

GoogleCodeExporter commented 9 years ago
It is not possible right now, to my knowledge.  It would require pretty 
invasive modifications to the profiling libraries, to keep track of a thread-id 
along with each allocation.  I'm not convinced this would be generally useful, 
and my first thought is I'd rather not complexify gperftools with this 
functionality.

If there's a single function you're worried about, perhaps you could modify the 
code so each thread calls the function under a different name?  This adds some 
complexity to your code, but may be worth it for you.

Original comment by csilv...@gmail.com on 2 Feb 2012 at 6:47

GoogleCodeExporter commented 9 years ago
this feature is more useful for cpu profiler than for heap checker / profiler.

for example, if we can divide cpu profiler's call graphs into different parts 
for different threads, it's more convenient to find out cpu bottleneck for 
individual thread.

Original comment by huas...@gmail.com on 2 Feb 2012 at 7:34

GoogleCodeExporter commented 9 years ago
Hmm, this isn't a need I've seen.  Do you really have a situation where a 
function is really cheap for one thread but expensive for others?  Anyway, 
you're welcome to try to code up a patch for it, but it's not something that is 
likely to happen unless you do it. :-)

Original comment by csilv...@gmail.com on 2 Feb 2012 at 9:53

GoogleCodeExporter commented 9 years ago
I am going to close this one off since there has been no interest now for a 
long time. If interest peaks we can always resurrect it.

Original comment by chapp...@gmail.com on 11 Mar 2013 at 2:10