doc: add runtime benchmarks
@@ -99,6 +99,20 @@ All other benchmarks saw meaningful reductions of heap memory used.
One interesting observation is that `kdbget.c` and `kdbmodify.c` used exactly the same memory.
This can most likely be explained by internal caching within the memory allocator of `glibc`.
+We also performed runtime tests on the same benchmarks using `perf stat --repeat 13`.
+
+| Benchmark | Current Implementation | Deviation | Copy-on-Write | Deviation | Runtime Increase |
+| :-------------- | ---------------------: | --------: | ------------: | --------: | ---------------: |
+| `createkeys.c` | 0.209572 s | 0.36 % | 0.21987 s | 0.77 % | 4.9 % |
+| `deepdup.c` | 0.23025 s | 0.47 % | 0.231804 s | 0.32 % | 0.6 % |
+| `large.c` | 1.14038 s | 0.21 % | 1.14837 s | 0.21 % | 0.7 % |
+| `kdb.c` | 1.9270 s | 2.63 % | 1.93354 s | 0.17 % | 0.3 % |
+| `kdbget.c` | 0.145663 s | 0.17 % | 0.15763 s | 0.70 % | 8.2 % |
+| `kdbmodify.c` | 0.146506 s | 0.19 % | 0.156347 s | 0.15 % | 6.7 % |
+
+Overall, the runtime performance hit is less than 10%.
+The more a program does, the less the additional overhead of the copy-on-write algorithms matter.
+
### <<HIGHLIGHT>>
### <<HIGHLIGHT>>
