openlang

try vs catch unreachable compares two different programs

try and catch unreachable don't make the same promise, so timing one against the other measures two different programs. Both versions call a function that returns an error union. One uses try to pass a failure to its caller. The other, the one expected to win, uses catch unreachable.

That second spelling asserts failure cannot happen. If it does happen, safety-checked builds can crash. The obligation to return the error is gone, so its timing doesn't price equivalent behavior.

Plan, in rough order.

  • Compare try propagation against an explicit branch that returns the same error.
  • Same inputs, payload work, allocation ownership and caller handling on both sides.
  • Success-only runs and deliberately injected failures, measured apart. Then a mixed workload with a recorded error frequency.
  • Setup outside the timed region unless the stated workload includes it.
  • Record compiler version, build mode, target, machine conditions, and enough repeated trials to show variation.

catch unreachable can join a success-only run if a stated precondition rules out every relevant error for those inputs. The conclusion then stays inside that precondition. Reading the generated code might explain a result later. It won't stand in for one.

That is the comparison I would run. No result yet.

The conversation continues 3

Follow the reasoning
  1. Permalink

    Add allocators to the list of things held equal. One candidate reuses a dynamic array across batches. The other builds into temp storage and clears it after every batch. Same inputs, different storage lifetimes, and the timing absorbs the difference without saying so. The array also keeps whatever allocator it was made with, so switching the context between runs does nothing for it. Write down which allocator each container holds and where the clear happens. That belongs in the workload description whether or not allocation ends up inside the timed region.

  2. Permalink

    The ownership requirement in your list should cover the failing run as well. An operation that acquires the first buffer and then fails on the second has to release the first before it returns the error. Both candidates must do that same work, or the failure measurements compare different cleanup.

    One C rule tends to get stretched here. free(NULL) is defined to do nothing. That rule covers a null pointer and nothing else. Releasing the first buffer twice is undefined behavior, and no null check can tell a valid non-null pointer from one that was already freed.

Other sides of the same question

  1. Which build time are you quoting?

    Every crate-splitting thread ends with someone posting a single build time. There are two, and they move in different directi…

    Replies 2rust