@@ -108,6 +108,29 @@ by the programmers to deem it usable.
108108See the [README](benchmark/README) file in the `benchmark` directory for more
109109details on how to run the benchmarks.
110110
111+The first level of check is the regression in "allocations", this is
112+the most stable measure of regression. "bytesCopied" is another stable
113+measure, it gives an idea of the amount of long lived data being copied
114+across generations of GC.
115+
116+The next measure to look at is "cpuTime" this may have some variance
117+from run to run because of factors like cpu frequency scaling, load on
118+the system or the number of context switches etc. However, the variance
119+would usually be within 5-10%, anything more than that is likely to be a
120+red flag.
121+
122+Quite often an increase in "cpuTime" would correspond to an increase
123+in "allocations". Increase in "allocations" indicates an inefficiency
124+in computing due to too much GC activity e.g. due to lack of
125+fusion. However, it is also possible for the cpu time to go up without
126+the allocations going up, this indicates an inefficiency in processing
127+in general or more CPU being used for the same task. It could be because
128+of inefficient code generation, branch mis-predictions or lack of cache
129+locality etc.
130+
131+For concurrent benchmarks we can compare "cpuTime" and "time" to check
132+the degree of concurrency and total efficiency.
133+
111134### Changelog
112135
113136Any new changes that affect the user of the library in some way must be