[ritvikrao]

Problem

When a PE is already idle when tracing begins, its log starts with an END_IDLE that has no BEGIN_IDLE before it. On such traces, Time Profile shows the whole run as overhead (solid black). Timeline is unaffected and shows the entry methods normally.

LogReader keeps a processing counter per PE, and addToInterval drops all time while that counter is <= 0. The unmatched END_IDLE takes the counter to -1. After that it only moves between -1 and 0, so every later idle and entry-method interval on the PE is dropped. Time Profile then computes overhead as interval − 0 idle − 0 work. Timeline uses its own parser, so it never hits this.

Seen on a Reconverse Barnes-Hut trace on 8 nodes × 15 PEs: all 120 PEs start with an unmatched END_IDLE. The same program on 1 node × 120 PEs starts with BEGIN_IDLE and was unaffected.

Fix

The read loop now tracks whether an idle period is open and skips an END_IDLE when none is. Unmatched END_PROCESSING events (isProcessing) are already handled the same way.

Testing

The repo has no unit tests, so I used a small headless harness. It loads each trace and runs every PE through the same LogReader.read() call the Time Profile uses, over the whole run in 10 ms intervals. Percentages are shares of total PE time.

Trace	Build	PEs with entry time	Entry (%)	Idle (%)	Overhead (%)
Barnes-Hut, 8 nodes × 15 PEs	main	1 / 120	0.0	0.0	100.0
Barnes-Hut, 8 nodes × 15 PEs	this PR	120 / 120	53.3	33.1	13.6
Barnes-Hut, 1 node × 120 PEs	main and this PR	120 / 120	14.7	82.0	3.3
test/hello (4 PEs)	main and this PR	4 / 4	2.6	14.6	82.7

Traces that were already correct give identical numbers. Most of the 13.6% overhead left on the 8 × 15 trace is the stretch before tracing begins (the first 410 ms of 3.4 s, 12.1%), which counts as overhead in both runs. The idle time before the first unmatched END_IDLE is also counted as overhead, since the log doesn't record when it started.

Not checked: the GUI itself (the harness calls the same read()), and the Overview tool, which also creates a LogReader.

🤖 Generated with Claude Code

[lvkale]

Approving. The diagnosis matches the code: the per-PE processing counter is driven by BEGIN/END_IDLE and BEGIN/END_PROCESSING, addToInterval only accumulates while it is positive, and an unmatched END_IDLE pins it at -1/0 for the rest of the PE. Skipping the END_IDLE is the right tolerance, and it parallels the existing unmatched-END_PROCESSING handling. Skipping intervalCalc also skips fillToInterval, which is harmless since the next event's fill catches up with the counter at zero.

Independent check: I built this branch and ran every PE of a trace through the same LogReader.read() call Time Profile uses, on main and on this branch.

Trace	main	this PR
test/hello, unmodified	4/4 PEs, entry 2.5%, idle 14.6%	identical
hello with the first BEGIN_IDLE deleted on PEs 1 and 2	PEs 1 and 2 report zero entry and zero idle	4/4 PEs restored; idle short by only the deleted span
hello with a mid-run BEGIN_IDLE deleted on PE 3	PE 3 loses everything after the gap	PE 3 fully restored

The mid-run case shows the fix is more general than the title: any unmatched END_IDLE, not only a leading one, used to zero the rest of the PE. Unmodified traces give identical numbers.

For the record, none of the .log traces on my machine (120-PE reconverse FoF3, all logs; 896-PE Frontier FoF3, first idle event of every log) start with END_IDLE, so the 8x15 Barnes-Hut trace is the only known instance. That points at a reconverse startup-ordering question (tracing initialized after the scheduler already went idle) worth raising on the charm side, independent of this fix.

Two non-blocking notes inline.

[lvkale]

Re-approving after 71cce6c and the merge of main. Verified the new guard independently: a copy of test/hello with one BEGIN_IDLE duplicated on PE 0 gives idle 20.8% on main and 14.6% with this branch (same as the unmodified trace), and the leading and mid-run unmatched END_IDLE cases from my first review still come out right. Agreed on leaving the pre-BEGIN_COMPUTATION stretch as overhead and taking the BEGIN_IDLE-at-trace-start question to the runtime.