rename Current Implementation -> Old Implementation; highlight speedup of keyCopy
@@ -81,8 +81,8 @@ This means noticeably reduced memory usage for cases where keys and keysets are
We run some very promising benchmarks, each were performed with 400,000 keys.
All benchmarks were executed using `valgrind --tool=massif --time-unit=B --max-snapshots=200 --threshold=0.1`.
-| Benchmark | Current Implementation | Copy-on-Write | Size Reduction | Remarks |
-| :------------- | ---------------------: | ------------: | -------------: | :------------------------- |
+| Benchmark | Old Implementation | Copy-on-Write | Size Reduction | Remarks |
+| :------------- | -----------------: | ------------: | -------------: | :------------------------- |
| `createkeys.c` | 5.3 MiB | 6.5 MiB | -22 % | |
| `deepdup.c` | 10.5 MiB | 8.2 MiB | 22 % | |
| `large.c` | 18.9 MiB | 15.3 MiB | 19 % | |
@@ -99,10 +99,10 @@ 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`.
+We also performed runtime tests on the same benchmarks using `perf stat --repeat 13` to ensure no major performance regressions occur.
-| Benchmark | Current Implementation | Deviation | Copy-on-Write | Deviation | Runtime Increase |
-| :-------------- | ---------------------: | --------: | ------------: | --------: | ---------------: |
+| Benchmark | Old 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 % |
@@ -112,6 +112,10 @@ We also performed runtime tests on the same benchmarks using `perf stat --repeat
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.
+One interesting detail is that `keyCopy` and `keyDup` have become quite a bit faster.
+This can be seen by comparing the differences between `createkeys.c` and `deepdup.c`.
+The differences are 21 ms for the old implementation and 12 ms for the copy-on-write implementation.
+
### <<HIGHLIGHT>>
