Skip to content

Render flamegraph diff#1

Open
sdmcclain wants to merge 2 commits into
masterfrom
render_flamegraph_diff
Open

Render flamegraph diff#1
sdmcclain wants to merge 2 commits into
masterfrom
render_flamegraph_diff

Conversation

@sdmcclain

@sdmcclain sdmcclain commented Apr 21, 2017

Copy link
Copy Markdown
Owner

Following on sdmcclain/FlameGraph#1:

  1. the function folded (which exists to process folded profiles), has been enhanced to use the Execution time passed in from difffolded.pl to add some additional context to the profiles:

When the time is "REALTIME" it's a regular diff (created without the -u option), and so we get a line similar to:

my_file.py:38 4 2

Looking at https://github.com/mcclaized/edav_final_project/tree/master/example/data, let's say this file is baseline_diff.folded and was created by running:

difffolded.pl fibonacci_bad.folded fibonacci_improved.folded

The above output means that line 38 of my_file.py was sampled 4 times during the profile of fibonacci_bad.py. The goal of this run of index.js -f baseline_diff.folded is to create baseline_diff.json which will be the basis of the "Baseline FlameGraph".

So, all we have to do to relate "4" calls of my_file.py to it's execution time is sum up the total number of calls at the root level, divide them by the runtime of the program, and then multiple that factor by 4. And that's exactly what this PR does :)

We can simply flip the order to generate the data for improved_diff.json:
difffolded.pl fibonacci_improved.folded fibonacci_bad.folded > improved_diff.folded

which gives us:
my_file.py:38 2 4

and then:
index.js -n -f improved_diff.folded

However! Notice the -n (short for negate) because we want to reverse the colors: for the improved_diff.folded, a smaller first number ("2" in this case) signifies fewer calls in our improved program, and should be marked with blue (meaning 👍 ) instead of red.

  1. Generating the diff_delta

This one was a little bit more complicated. The third FlameGraph showing the delta should have all of the diffs between the baseline and improved but since some are positive and some are negative, we can't find the proportion simply by dividing the total number of calls at the root level and dividing by the runtime. We need to iteratively keep track of how much net time is being added/subtracted (called timeshare) for each function call (using the diff of -1 or +1 to signify this), and divide by this number instead.

Take a look at lines 180:183, 17:20, and 186 to see the logic in code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant