You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| Process (ephemeral) |342.67ms|347.26ms|354.62ms|
20
+
| Process (pooled) | 2.11ms| 3.47ms|4.86ms|
21
21
22
22
### Notes
23
23
24
24
- On this machine, warmed pooled executors stayed close to QuickJS for trivial scripts.
25
25
- Ephemeral executors remained far slower than pooled executors because each execution still pays worker or process startup cost.
26
-
- Process pooled stayed competitive for median latency, but its variance was visibly wider than worker pooled in the later throughput and contention suites.
26
+
- Process pooled stayed low-latency in median terms, but its variability was still visibly wider than worker pooled on the no-tool case.
27
27
28
28
---
29
29
@@ -33,54 +33,54 @@ Only pooled executors expose explicit `prewarm()`. QuickJS and ephemeral executo
- True `prewarm()`materially changed first-request behavior in this run: both pooled worker and pooled process executors dropped from shell-plus-guest startup latency to low-single-digit warm execution latency.
45
-
-That is the intended effect of prewarm after the benchmark harness and executor updates: pay the host-shell and guest-startup path before live traffic arrives.
44
+
- True `prewarm()`delivered the intended first-request behavior in this run: pooled worker and pooled process executors dropped from shell-plus-guest startup latency to low-single-digit warm execution latency.
45
+
-`prewarm()` pays the host-shell and guest-startup path before live traffic arrives.
- Tool-call cost still scaled roughly linearly in this run.
69
-
-Worker pooled carried a slightly higher per-call overhead than QuickJS, but the absolute delta stayed small compared with the startup gap between pooled and ephemeral execution modes.
69
+
-QuickJS and worker pooled stayed close enough that real tool work is still likely to dominate end-to-end latency once tools do anything non-trivial.
70
70
71
71
---
72
72
73
73
## 4. Schema Validation Overhead
74
74
75
-
| Executor | With Schema (median) | Without Schema (median) | Overhead |
@@ -143,9 +143,9 @@ This suite only measures the parent Node process. It does not attempt to attribu
143
143
### High-value takeaways from this snapshot
144
144
145
145
- QuickJS remained the lowest-latency and highest-throughput option for trusted, in-process workloads on this machine.
146
-
- True `prewarm()`now delivered the intended first-request benefit for pooled worker and pooled process executors in this run.
146
+
- True `prewarm()` delivered the intended first-request benefit for pooled worker and pooled process executors.
147
147
- Worker pooled remained the strongest general-purpose local trade-off between isolation, throughput, and tail latency.
148
-
- Process pooled stayed viable when process isolation matters, but its concurrency and contention behavior was more workload-sensitive in this snapshot.
148
+
- Process pooled stayed viable when process isolation matters, but it still trailed worker pooled on throughput and tail latency.
149
149
- Ephemeral modes remained dramatically slower than pooled modes and are best reserved for cases that need a fresh host boundary per execution.
0 commit comments