Observe runtime behavior.

Compare representative snapshots.

Take snapshots during idle operation, representative load, and recovery. Group snapshots are coherent, but they briefly hold scheduler locks and cost O(group members). Sample periodically instead of sampling each request.

Because lifetime counters wrap and do not reset, compare two samples instead of using one cumulative value as a rate.

Measure how busy an event loop is

A group's event loop blocks in its poller only when no task in that group can run. The runtime times that wait, so a snapshot reports the loop's elapsed time and the part of it the loop spent idle. Subtract one from the other to get the time the loop spent running task code and its own scheduler work.

A snapshot never reports more idle time than elapsed time, and it includes a poller wait that is still in progress. The subtraction is therefore always valid, even while the loop is blocked.

declare
   use type Flyology.Observability.Counter;
   Sample : Flyology.Observability.Group_Snapshot;
begin
   if Flyology.Observability.Snapshot (0, Sample) then
      Ada.Text_IO.Put_Line
        ("uptime ns=" & Sample.Uptime_Nanoseconds'Image
         & " idle ns=" & Sample.Idle_Nanoseconds'Image
         & " busy ns="
         & Flyology.Observability.Counter'Image
             (Sample.Uptime_Nanoseconds - Sample.Idle_Nanoseconds)
         & " poller waits=" & Sample.Idle_Waits'Image);
   end if;
end;

Counter is declared in another package, so its operators need a use type clause before the subtraction.

Both values cover the loop's whole lifetime, so one sample reports an average and not current load. Take two samples and subtract each field to measure one interval.

The measure describes the event loop, not the tasks on it. Two situations look alike:

• A group whose tasks all wait on readiness or a deadline reports mostly idle time, and so does a group with nothing to do. Read Waiting and Members to separate them.
• A task that runs CPU code without reaching a suspension point keeps its loop out of the poller. That group reports as fully busy with one task running, which cooperative checkpoints address.

Idle_Waits counts the blocking poller waits behind those totals. Divide it by the elapsed time to get the rate at which the loop ran out of runnable work.

The runtime reads the monotonic clock twice for each blocking poller wait and never during a dispatch. This cost follows how often a loop runs out of work, not how much work it does. On the checked macOS/AArch64 host, one reading costs about 20 ns. A loop that only exchanges socket messages reaches about 32,000 to 38,000 waits per second. Run scripts/bench-runtime.sh to measure both values on the target host.

./scripts/showcases.sh

# After the showcase build, choose smaller local counts if needed:
./showcases/run_connection_density.sh 1000 10000
./showcases/run_event_loop_pool.sh 1024 20 4
./showcases/run_dormant_stack_pressure.sh 128 64

The density run compares lightweight and native tasks with the same requested stack size. It reports RSS, virtual address space, thread count, and lightweight stack-pool counters. The pool run compares one event loop with a configured pool under repeated readiness activity.

The dormant-stack run compares Prompt, Reclaimable, and Page_Out in separate processes. It verifies every modified stack payload after wake. Treat each result as a measurement of the tested host and workload, not as a universal sizing constant.