JInterface: improve OtpOutputStream buffer allocation

Previously, the buffer was increased linearly by 2048 bytes.
I now propose to use an exponential increase function
(similar to Javas ArrayList, e.g. always at least +50%).
This significantly increases performance of e.g. doRPC for
large parameters as the following comparison illustrates
(shown is the buffer size after each time, the buffer has reached its limit):

n    n*2048       (n*3)/2+1    (n*3)/2+1 (at least +2048)
1     2,048           2,048          2,048
2     4,096           3,073          4,096
3     6,144           4,610          6,145
4     8,192           6,916          9,218
5     10,240         10,375         13,828
6     12,288         15,563         20,743
7     14,336         23,345         31,115
8     16,384         35,018         46,673
9     18,432         52,528         70,010
10    20,480         78,793        105,016
11    22,528        118,190        157,525
12    24,576        177,286        236,288
13    26,624        265,930        354,433
14    28,672        398,896        531,650
15    30,720        598,345        797,476
16    32,768        897,518      1,196,215
17    34,816      1,346,278      1,794,323
18    36,864      2,019,418      2,691,485
19    38,912      3,029,128      4,037,228
20    40,960      4,543,693      6,055,843
21    43,008      6,815,540      9,083,765
22    45,056     10,223,311     13,625,648
23    47,104     15,334,967     20,438,473
24    49,152     23,002,451     30,657,710
25    51,200     34,503,677     45,986,566
26    53,248     51,755,516     68,979,850
27    55,296     77,633,275    103,469,776
28    57,344    116,449,913    155,204,665
29    59,392    174,674,870    232,806,998
30    61,440    262,012,306    349,210,498

Actually, ArrayList uses the (n*3)/2+1 strategy. In order not to
decrease performance for messages <10k, we could keep the (public)
OtpOutputStream#defaultIncrement constant and let the buffer always
increase by at least this much (third column).

In order to create a buffer of 1MB, now only 16 array copies are
needed vs. (1024*1024/2048)=512 array copies for the linear increase
function. If a user sends a message of 10MB size, this is 22 vs.
5120 copies.

NOTE: the meaning of the "public static final int defaultIncrement"
member has changed a bit with this implementation (API compatibility?)
- why was this public in the first place?

0 files changed, 0 insertions, 0 deletions