The following logs were captured on a Dual-Core Apollo Lake Celeron during a high-concurrency stress test (1,000 cycles of 100,000 allocations).

The top command reveals a radical difference in how each runtime claims system resources.

Note: Go's <1ms result reflects Deferred Debt, where deallocation is bypassed during the measurement window.

While Go reports low physical memory (RES), its Virtual Memory (VIRT) is 115x higher than Nodepp. In safety-critical systems, high VIRT can lead to address-space exhaustion. Bun's 69GB VIRT and 72MB RES make it unsuitable for memory-constrained embedded hardware.

g++ -o main nodepp_benchmark.cpp -O3 ; ./main

Nodepp shows absolute stability. Every cycle takes exactly 3ms. This is the result of RAII (Resource Acquisition Is Initialization), where memory is freed immediately without Stop-the-World pauses.

PID   | USUARIO | PR | NI | VIRT | RES  | SHR  | S | %CPU | %MEM | HORA+   | ORDEN   
23781 | penguin | 20 | 0  | 6196 | 2776 | 2764 | R | 61,4 | 0,1  | 0:00.80 | main  
...
986 Nodepp Time: 3 ms 
987 Nodepp Time: 3 ms 
988 Nodepp Time: 3 ms 
989 Nodepp Time: 3 ms 
990 Nodepp Time: 3 ms 
991 Nodepp Time: 3 ms 
992 Nodepp Time: 3 ms 
993 Nodepp Time: 3 ms 
994 Nodepp Time: 3 ms 
995 Nodepp Time: 3 ms 
996 Nodepp Time: 3 ms 
997 Nodepp Time: 3 ms 
998 Nodepp Time: 3 ms 
999 Nodepp Time: 3 ms 
1000 Nodepp Time: 3 ms (p100: 3ms)

Bun exhibits Latency Jitter. Notice how the time jumps from 5ms to 11ms. This 120% variance is caused by the Garbage Collector waking up to clean memory, which would cause stuttering in a real-time control system.

PID   | USUARIO | PR | NI | VIRT  | RES   | SHR   | S | %CPU | %MEM | HORA+   | ORDEN       
24212 | penguin | 20 | 0  | 69,3g | 72696 | 33576 | R | 28,3 | 1,9  | 0:00.86 | bun
...
986 Bun Time: 7 ms
987 Bun Time: 7 ms
988 Bun Time: 6 ms
989 Bun Time: 9 ms
990 Bun Time: 7 ms
991 Bun Time: 6 ms
992 Bun Time: 7 ms
993 Bun Time: 6 ms
994 Bun Time: 11 ms (Jitter Spike)
995 Bun Time: 11 ms
996 Bun Time: 5 ms
997 Bun Time: 6 ms
998 Bun Time: 5 ms
999 Bun Time: 9 ms
1000 Bun Time: 6 ms

Go reports 0ms for many cycles. While this looks fast, it is a lie of omission. Go's GC is deferring the work of deallocation to a background thread. While the main task finishes quickly, the CPU is still burdened by background scavenging, which is why Go’s %CPU (77.2%) is higher than Nodepp’s (61.4%).

PID   | USUARIO | PR | NI | VIRT   | RES  | SHR  | S | %CPU | %MEM | HORA+   | ORDEN       
24591 | penguin | 26 | 6  | 703172 | 2220 | 1084 | R | 77,2 | 0,1  | 0:00.86 | golan_benc+
...
985 Go Time: 0 ms
986 Go Time: 1 ms
987 Go Time: 0 ms
988 Go Time: 0 ms
989 Go Time: 0 ms
990 Go Time: 0 ms
991 Go Time: 0 ms
992 Go Time: 1 ms
993 Go Time: 0 ms
994 Go Time: 0 ms
995 Go Time: 2 ms (GC Event)
996 Go Time: 0 ms
997 Go Time: 0 ms
998 Go Time: 0 ms
999 Go Time: 0 ms
1000 Go Time: 0 ms

The data confirms that Nodepp operates with Silicon Parity.

• CPU Efficiency: Nodepp achieved its results with the lowest overall CPU load per lifecycle event.

• Reliability: The flat 3ms line proves that Nodepp can be used for hard-deadline tasks where spikes would result in a system failure.