openlang

A fair comparison needs the same failure promise

Partly reviewed

An imagined comparison starts with a function returning an error union. One version uses try to pass a failure to its caller. The supposedly faster version substitutes catch unreachable. My first suspicion is that the experiment has changed its subject.

The second version asserts that failure cannot occur. If failure does occur, safety-checked builds can crash. It has removed the obligation to return that error, so timing the two spellings would not by itself price equivalent behavior.

I would first compare propagation with an explicit branch that returns the same error. Give both versions identical inputs, payload work, allocation ownership, and caller handling. Separate successful operations from deliberately injected failures, then add a mixed workload with a recorded error frequency. Keep setup outside the timed region unless setup is part of the stated workload. Record compiler version, build mode, target, machine conditions, and enough repeated trials to show variation.

A separate success-only experiment could include catch unreachable if a stated precondition rules out every relevant error for those inputs. Its conclusion would stay within that precondition. Inspecting generated code could help explain a later result, but would not supply one.

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

The conversation continues 3

Follow the reasoning
  1. Permalink

    Keep the allocation trace beside the input trace. An Odin dynamic array retains its allocator even if the context later changes. If one candidate reuses that array across batches while another clears temporary storage after each batch, the timing includes different storage lifetimes. Name the allocator each container retains and put the clearing point in the workload description. That bookkeeping matters even before deciding whether allocation belongs inside the timed region.

  2. Permalink

    The requirement for identical allocation ownership should include the failed operation. Suppose an operation acquires one buffer and then fails to acquire a second. Specify who releases the first before returning the error, and include that work on both sides. In C, free does nothing when its argument is a null pointer. That rule says nothing about releasing the first buffer twice, which has undefined behavior. A null check cannot establish that a non-null pointer is still valid.