Turn the part on memory use into a dedicated subsection

Author: jeltsch

doc/final-report/final-report.md

@@ -1250,42 +1250,6 @@ can be interleaved with the database operations then using more cores can
 improve performance even more. With the real UTxO workload, we are in this
 situation, of course, because there is transaction validation work to do.
 
-### The memory targets
-
-Performance requirement 7 states:
-
-> A benchmark should demonstrate that the memory use of a table with 10 M
-> entries is within 100 Mb, and a 100 M entry table is within 1 Gb. This should
-> be for key value sizes as in the primary benchmark (34 + 60 bytes).
-
-The table in the [Primary Benchmark Results] section reports the results for a
-table with 100 M entries. The last column is the maximum memory used during the
-run. As noted in the table description, the memory measurement is the peak RSS,
-as reported by the OS.
-
-We can see from the reported memory use that all the benchmark runs work in
-less than 1 GiB (1024 MiB).
-
-For the target of the 10 M entry table operating within 100 Mb, we have to use
-a slightly different benchmark configuration.
-
- * Obviously we must use a smaller table, with an initial size of 10 M entries.
- * We also scale down the size of the write buffer correspondingly, from 20k
-   entries to 2k entries.
- * We tell the GHC RTS to limit its heap size to 100 Mb, using: `+RTS -M100m`.
-
-One minor "gotcha" to avoid, when reproducing this result, is that one has to
-run the benchmark executable directly, not via `cabal run`. This is because
-`/usr/bin/time` reports the largest RSS of any sub-process which may turn out
-to be from `cabal` itself, and not the benchmark process.
-
-With this, the RSS is reported as 85,220 Kb, 83.2 Mb, which is less than the
-target of 100 Mb.
-
-We also get excellent performance results for smaller tables like this, since
-there is less merging work to do. In this case we get around 150k ops/sec,
-compared to around 86k ops/sec for the 100 M entry table.
-
 ### Reproducing the results
 
 The primary benchmark’s code is in the repository in
@@ -1388,6 +1352,42 @@ The result are as follows
    upsert is "substantially better" than the combination of a lookup followed
    by an insert.
 
+## The memory targets
+
+Performance requirement 7 states:
+
+> A benchmark should demonstrate that the memory use of a table with 10 M
+> entries is within 100 Mb, and a 100 M entry table is within 1 Gb. This should
+> be for key value sizes as in the primary benchmark (34 + 60 bytes).
+
+The table in the [Primary Benchmark Results] section reports the results for a
+table with 100 M entries. The last column is the maximum memory used during the
+run. As noted in the table description, the memory measurement is the peak RSS,
+as reported by the OS.
+
+We can see from the reported memory use that all the benchmark runs work in
+less than 1 GiB (1024 MiB).
+
+For the target of the 10 M entry table operating within 100 Mb, we have to use
+a slightly different benchmark configuration.
+
+ * Obviously we must use a smaller table, with an initial size of 10 M entries.
+ * We also scale down the size of the write buffer correspondingly, from 20k
+   entries to 2k entries.
+ * We tell the GHC RTS to limit its heap size to 100 Mb, using: `+RTS -M100m`.
+
+One minor "gotcha" to avoid, when reproducing this result, is that one has to
+run the benchmark executable directly, not via `cabal run`. This is because
+`/usr/bin/time` reports the largest RSS of any sub-process which may turn out
+to be from `cabal` itself, and not the benchmark process.
+
+With this, the RSS is reported as 85,220 Kb, 83.2 Mb, which is less than the
+target of 100 Mb.
+
+We also get excellent performance results for smaller tables like this, since
+there is less merging work to do. In this case we get around 150k ops/sec,
+compared to around 86k ops/sec for the 100 M entry table.
+
 # References {-}
 
 ::: {#refs}