try vs catch unreachable in a hot loop, numbers make no sense

I'm timing try parseLine(line) against parseLine(line) catch unreachable over ~2M generated ts,level,bytes lines, summing the bytes. Built with -Doptimize=ReleaseFast.

The try run reports a few hundred microseconds and prints an error name instead of a total. The catch unreachable run takes tens of ms, and its total is different. ReleaseSafe and Debug panic on the second one. I added a corrupt line every 5000 lines to "make it realistic". With --bad-every 0 things look saner, but I don't get why it matters this much.

The two loops:

const e = try parse.parseLine(line);
total += e.bytes;
// vs
const e = parse.parseLine(line) catch unreachable;
total += e.bytes;

My guesses were error return traces or inlining. I haven't looked at the assembly yet. Input generation is already outside the timer. (splitScalar showed up around 0.12, I think, nvm if that's off.)

So what is this actually measuring? Thanks for any pointers.

The conversation continues 2

Follow the reasoning

brin4023 Aug Permalink
You're not comparing two ways of handling the same work. The try run is bailing out at the first bad line. A few hundred µs for 2M lines means it barely got started, and the error name you see is the one from that early return. If your generator does i % 5000 == 0, line 0 is already corrupt, so it dies straight away.

The catch unreachable run is a different problem. In ReleaseFast that's undefined behaviour on the first bad line, so the optimiser can do whatever it likes. That's why the total is off. Debug and ReleaseSafe panic because they actually check. The tens of ms isn't a number you can trust either, since the compiler may have folded the loop into something odd.

I'd bench it with zero bad lines first, then bad lines handled with catch continue or a counter. Compare those. Print how many lines were actually parsed alongside the total, so you know the loop ran to the end.

Honestly it looks like a codegen quirk to me, so I'd check your Zig version too. Which build are you on?
pothos23 Aug Permalink
Following an earlier reply ↗

A few hundred µs for 2M lines means it barely got started

same here, mine died on line 0 too. my generator had i % N == 0.

try vs catch unreachable in a hot loop, numbers make no sense

The conversation continues 2

Other sides of the same question

simple loops very slow, gfortran, 200000 x 64 array

running_mean slow, time goes to memmove not arithmetic

Which build time are you quoting?