Skip to content

Comparing profiles

What changed between two profiles, and before and after a deploy.

Comparing profiles

One profile says where the time goes. Two say what changed: after a deploy, after a configuration change, or between a quiet hour and a busy one.

Choosing two profiles

Any two finished profiles of the same type can be compared: two CPU profiles, or two wall-clock profiles, but not one of each.

  • In a Service's Past profiles, tick two and press Compare these two. Ticking a third replaces the oldest choice.
  • Each profile in the list offers Compare with the one before, the previous profile of the same type for the same Service, in one click.
  • On the Profiles page, tick any two of the same type, across Services too.

The earlier profile is always before and the later one after, whichever you ticked first.

Before and after a deploy

The Performance tab looks for the latest deploy of the Service and pairs the closest finished profiles of one type on either side of it:

  • When both exist: Compare before and after.
  • When only the one before exists: Capture 30 s and compare captures the same type now, and opens the comparison by itself when it finishes.
  • When there is none from before: it says so. Capture one now, and the next deploy can be compared before and after. Continuous profiling means there always is one.

Every successful deploy in the Service's Activity has a Compare performance before and after link, which opens the Performance tab on that deploy.

Reading the comparison

The page starts with one sentence, for example:

build_report went from 12% to 41% of the CPU time after the deploy at 14:05. Overall the Service used 2.1 times as much CPU.

It names the function whose share moved most, preferring your own code, and the latest deploy between the two captures when there was one, at your local time. For CPU it adds whether the Service as a whole got busier or quieter. When nothing moved by 5 points or more, it says that instead.

Under it, the whole Service's rate before and after, such as "427 ms of CPU time per second before, 1.00 s after", per second so captures of different lengths compare fairly.

Why shares, not raw time

Two captures rarely see exactly the same load. If traffic doubled, every function takes twice the time and nothing has really changed. So the comparison is in shares of the whole: a function that went from 12% to 41% changed, whatever the load was.

The graph

The graph is the after profile, with each box coloured by how its share moved:

ColourMeaning
RedA larger share after; the deeper the red, the more
BlueA smaller share after
GreyAbout the same

Full colour is 10 points of change. Hover a box for its share before, its share after, and the change in points. Search, zoom, the keyboard and Show every frame work as on a single profile; see Reading a flame graph.

A function that is gone entirely has no width in the after profile, so it cannot be drawn. It is listed in the table instead.

What moved

The table lists every function whose share moved by half a point or more, biggest moves first, with its share before and after and the change, such as +29 pts. Functions that are new are marked new, and those that disappeared gone. Click a name to find it in the graph.

Comparing across Services

From the Profiles page you can compare two different Services, or two servers, for example the same application on two machines. The sentence then speaks of the first profile and the second rather than before and after, and no deploy is named.