is flame graph call stack truncated?

[Brian Craft]

I'm looking at a flame graph for a tight rendering loop. It doesn't look like "flames". It looks like a rectangle, flat-topped. Adjacent call stacks look odd, like

EF

DE

CD

BC

AB

(where I've replaced function names with A-F). That is, they look like the same call stack, shifted. I was expecting instead to see something like

 F

E-

D-

C-

B-

A-

where A calls B calls C calls D calls E, which burns some CPU, then calls F, which burns a bit more.

Not sure how to interpret the flame graph I actually get, above. I'm wondering if a deep call graph is messing up the tool. The call stacks are deep. I can't see the top of the flame graph unless I make the font microscopic. There doesn't appear to be a vertical scroll option on the flame graph.

Is there a vertical scroll on the flame graph?

Will a deep call stack be truncated?

Will a deep call stack mess up the vertical alignment of adjacent time slices?

[Yury Semikhatsky]

On Wed, Jun 18, 2014 at 6:40 AM, Brian Craft <craft...@gmail.com> wrote:

I'm looking at a flame graph for a tight rendering loop. It doesn't look like "flames". It looks like a rectangle, flat-topped. Adjacent call stacks look odd, like

EF

DE

CD

BC

AB

(where I've replaced function names with A-F). That is, they look like the same call stack, shifted. I was expecting instead to see something like

 F

E-

D-

C-

B-

A-

where A calls B calls C calls D calls E, which burns some CPU, then calls F, which burns a bit more.

Not sure how to interpret the flame graph I actually get, above. I'm wondering if a deep call graph is messing up the tool. The call stacks are deep. I can't see the top of the flame graph unless I make the font microscopic. There doesn't appear to be a vertical scroll option on the flame graph.

Is there a vertical scroll on the flame graph?

Yes, there is one, you can see it if you resize the chart. It seems that in your case the problem is that the stacks are actually truncated.

 

Will a deep call stack be truncated?

Yes. Current limitation is 64 stack frames per sample. In other words the profiler will capture only top 64 frames.

 

Will a deep call stack mess up the vertical alignment of adjacent time slices?

Yes as two adjacent call stacks will have different base. This is a known issue https://code.google.com/p/chromium/issues/detail?id=233145 and we are going to address it.

 

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/cacae3ad-a623-47d3-909d-0da85fe0b2f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Craft]

Thanks. Is it not possible to align frames by identity, rather than order in the call stack? I'd rather lose the bottom of the call stack than have to degrade the profiler capture rate by repeatedly walking the part of the call stack that isn't changing. 

To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

[Yury Semikhatsky]

It could be possible. In the current implementation we store only pc for each stack frame while what you suggest would require to additionally store address of each stack frame so that we could match current call stack with the one in the previous sample and check if they have common part. But I agree that it might be a better option than just increasing sample size.

To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/b6f4350f-4654-4149-91c8-5046341b9d63%40googlegroups.com.

[Brian Craft]

Being completely ignorant of the code, I expect you could then stop walking the stack frames when you hit a frame from the previous sample, which could be faster than always doing 64. Much of the time it's only the last few frames that's different between samples.