Update the performance of SharedArray for v0.31.0 (#229)

Author: mstoykov

src/data/markdown/docs/02 javascript api/04 k6-data/1-SharedArray.md

@@ -2,25 +2,18 @@
 title: SharedArray
 ---
 
-`SharedArray` is an array-like object that shares the underlying memory between VUs. Its constructor
-takes a name for the `SharedArray` and a function which needs to return an array object itself. The
-function will be executed only once and its result will then be saved in memory once and copies
-of the elements will be given when requested. The name is needed as VUs are completely separate JS
-VMs and k6 needs some way to identify the `SharedArray`s that it needs to return. 
+`SharedArray` is an array-like object that shares the underlying memory between VUs. Its constructor takes a name for the `SharedArray` and a function which needs to return an array object itself. The function will be executed only once and its result will then be saved in memory once and copies of the elements will be given when requested. The name is needed as VUs are completely separate JS VMs and k6 needs some way to identify the `SharedArray`s that it needs to return.
 
-This does mean that you can have multiple such ones and even only load some of them for given VUs, although that is
-unlikely to have any performance benefit.
+This does mean that you can have multiple such ones and even only load some of them for given VUs, although that is unlikely to have any performance benefit.
 
-Everything about `SharedArray` is read-only once it is constructed, so it is not possible to
-communicate between VUs using it.
+Everything about `SharedArray` is read-only once it is constructed, so it is not possible to communicate between VUs using it.
 
 Supported operations include:
 1. getting the number of elements with `length`
 2. getting an element by its index using the normal syntax `array[index]`
 3. using `for-of` loops
 
-Which means that for the most part if you currently have an array data structure that you want to
-take less memory you can just wrap it in `SharedArray` and it should work for most cases.
+Which means that for the most part if you currently have an array data structure that you want to take less memory you can just wrap it in `SharedArray` and it should work for most cases.
 
 ### Examples
 
@@ -30,7 +23,7 @@ take less memory you can just wrap it in `SharedArray` and it should work for mo
 import { SharedArray } from "k6/data";
 
 var data = new SharedArray("some name", function() {
-    // here you can open files, and then do additional processing on them or just generate the data dynamically 
+    // here you can open files, and then do additional processing on them or just generate the data dynamically
     var f = JSON.parse(open("./somefile.json")).;
     return f; // f must be an array
 });
@@ -45,12 +38,9 @@ export default () => {
 
 ## Performance characteristics
 
-As the `SharedArray` is keeping the data marshalled as JSON and unmarshals elements when requested it
-does take additional time to unmarshal JSONs and generate objects that then need to be garbage collected.
+As the `SharedArray` is keeping the data marshalled as JSON and unmarshals elements when requested it does take additional time to unmarshal JSONs and generate objects that then need to be garbage collected.
 
-This in general should be unnoticeable compared to whatever you are doing with the data, but might
-mean that for small sets of data it is better to not use `SharedArray`, although your mileage may
-vary.
+This in general should be unnoticeable compared to whatever you are doing with the data, but might mean that for small sets of data it is better to not use `SharedArray`, although your mileage may vary.
 
 As an example the following script:
 
@@ -86,18 +76,20 @@ export default function () {
 
 </div>
 
-Which was ran with v0.30.0 and 100 VUs started to even out the CPU usage around 10k elements, but also was using 1/3 of the memory. At 100k `SharedArray` was the clear winner, while for lower numbers it is possible that not using it will help with performance.
+Which was ran with v0.31.0 and 100 VUs. As can be seen from the table below, there isn't much of a difference at lower numbers of data lines - up until around 1000 data lines there is little benefit in memory usage. But also there is little to no difference in CPU usage as well. At 10k and above, the memory savings start to heavily translate to CPU ones.
 
-| data lines | shared | wall time | CPU %    | mem usage   | http requests |
+| data lines | shared | wall time | CPU %    | MEM usage   | http requests |
 | ---        | ---    | ---       | ---      |  ----       | ---           |
-| 100        | true   | 2:02:50   | 86-90%   | 509-517MB   | 90248-92979   |
-| 100        | false  | 2:02:50   | 76-80%   | 512-533MB   | 92534-94666   |
-| 1000       | true   | 2:03:00   | 86-92%   | 509-519MB   | 92007-95234   |
-| 1000       | false  | 2:02:60   | 78-80%   | 621-630MB   | 92814-94526   |
-| 10000      | true   | 2:02:70   | 88-95%   | 515-523MB   | 92936-94997   |
-| 10000      | false  | 2:03:80   | 81-85%   | 1650-1675MB | 92339-95083   |
-| 100000     | true   | 2:04:50   | 89-91%   | 528-531MB   | 92274-93987   |
-| 100000     | false  | 2:15:00   | 115-123% | 8.9-9.5GB   | 90416-94817   |
+| 100        | true   | 2:01:70   | 70-79%   | 213-217MB   | 92191-98837   |
+| 100        | false  | 2:01:80   | 74-75%   | 224-232MB   | 96851-98643   |
+| 1000       | true   | 2:01:60   | 74-79%   | 209-216MB   | 98251-98806   |
+| 1000       | false  | 2:01:90   | 75-77%   | 333-339MB   | 98069-98951   |
+| 10000      | true   | 2:01:70   | 78-79%   | 213-217MB   | 97953-98735   |
+| 10000      | false  | 2:03:00   | 80-83%   | 1364-1400MB | 96816-98852   |
+| 100000     | true   | 2:02:20   | 78-79%   | 238-275MB   | 98103-98540   |
+| 100000     | false  | 2:14:00   | 120-124% | 8.3-9.1GB   | 96003-97802   |
+
+In v0.30.0 the difference in CPU usage at lower numbers was around 10-15%, but it also started to even out at around 10k data lines and was a clear winner at 100k.
 
 The CPU/memory data comes from using `/usr/bin/time` and the raw data can be found [here](https://gist.github.com/MStoykov/1181cfa6f00bc56b90915155f885e2bb).