Replace duplicated pool warmup blocks with a shared warm_pool() helper
that registers and replaces items twice to populate the recycling pool
before the benchmark loop begins.
Add Scheduler_SetTimeout_ExceedPool with batch size 10 (exceeding
MAX_POOL_SIZE=5) to measure the performance impact when the recycling
pool is exhausted and items must be malloc'd/freed each cycle.
Instead of draining after every single registration or batching 5,
use a batch size of 3 which represents a realistic worst case where
multiple components schedule in the same loop iteration while staying
within the recycling pool (MAX_POOL_SIZE=5).
Scheduler registration benchmarks (SetTimeout, SetInterval, Defer) were
not calling scheduler.call() periodically to drain and clean up cancelled
items. In production, call() runs every loop iteration, keeping the
scheduler containers small. Without draining, cancelled items accumulated
causing O(n²) scan cost in cancel_item_locked_ that doesn't reflect
real-world behavior.
- SetTimeout: was only calling process_to_add() (no cleanup), now calls
call() every kKeyCount iterations
- SetInterval: was calling process_to_add() (no cleanup of items_), now
calls call() for proper cleanup
- Defer: was never draining the defer queue, now calls call() to process
deferred items as production does
- All three now advance time (++now) to match production loop behavior
J. Nick Koston