@@ -108,6 +108,29 @@ by the programmers to deem it usable.
108See the [README](benchmark/README) file in the `benchmark` directory for more
108See the [README](benchmark/README) file in the `benchmark` directory for more
109details on how to run the benchmarks.
109details on how to run the benchmarks.
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.
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
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
131+For concurrent benchmarks we can compare "cpuTime" and "time" to check
132+the degree of concurrency and total efficiency.
111### Changelog
134### Changelog
113Any new changes that affect the user of the library in some way must be
136Any new changes that affect the user of the library in some way must be