Comparing Jobs

The Compare tab puts two jobs side by side: a metrics table with the change between them, and an overlaid chart with a selector for CPU efficiency, memory, or process and thread counts.

The pickers list every discovered job, including running jobs and jobs whose state is unknown. The comparison needs a merged whole-run summary for each job; a still-running job normally has no summary yet. If either summary is missing, the tab says which one.

Percentages change in points

Efficiency going from 37% to 58% reports +21.3pp, not "+57%".

Those are different claims. "+57%" is the relative change and sounds like a transformation; "+21.3 percentage points" is what actually happened. The tab uses points for anything already expressed as a percentage, and relative change only for absolute quantities like core-hours.

A change from a zero baseline has no meaningful relative percentage, so the table shows the absolute difference instead of an infinite percentage.

Aligned from each job's own start

Both lines are drawn from elapsed time, not wall-clock time, so runs days apart line up at zero. A shorter run's line simply stops where it ended rather than being bridged across time the job did not run.

The two series are resampled onto a shared grid. Merging their timestamps instead would leave each line with gaps wherever the other job happened to have a sample, which renders as dots rather than lines.

The chart has a Time window menu and zoom controls. Like the job charts, its sample series is bounded in memory, so a very long run may show only its recent portion. The metrics table still uses the complete merged summaries.

It flags, it does not rank

The tab tells you what makes a pair hard to compare rather than declaring a winner:

• different core or node counts
• different job names
• different queues
• missing or partly reported nodes in either run
• a non-zero or unrecorded exit status

It cannot know the two runs did the same work. A lower total may just mean less of it — a job that crashed at hour two will look wonderfully cheap.

That is the whole reason it does not pick a winner. The comparison is a tool for you to reason with, not a verdict.

What to actually compare

The useful pairs are ones where you changed one thing:

• the same case at two core counts, to see whether it scales
• the same case before and after a code change
• the same case on two queues or two node types

Comparing two unrelated jobs will produce numbers, and they will not mean much.