stream: change bufferlist to fixedqueue

[benjamingr]

Strings are still broken, this isn't optimal and is just an attempt to use FixedQueue instead of BufferList in Readable cc @ronag (I think we can do better and stick with a growing/shrinkng FixedQueue btw due to the "inter buffer slicing")

cc @ronag @anonrig

This is WIP

[nodejs-github-bot]

Review requested:

• @nodejs/streams

[benjamingr]

https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1404/

[rluvaton]

Suggested change

	// n < this.tail.top - this.tail.bottom but accountng to othe fact
	// n < this.tail.top - this.tail.bottom but accounting for other fact

[rluvaton]

ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1404

02:43:19.569                                                 confidence improvement accuracy (*)   (**)  (***)
02:43:19.569 streams/creation.js kind='duplex' n=50000000           ***    -76.62 %       ±1.36% ±1.84% ±2.43%
02:43:19.569 streams/creation.js kind='readable' n=50000000         ***    -87.63 %       ±1.28% ±1.73% ±2.30%
02:43:19.569 streams/creation.js kind='transform' n=50000000        ***    -76.48 %       ±2.61% ±3.51% ±4.66%
02:43:19.569 streams/creation.js kind='writable' n=50000000         ***      5.75 %       ±2.59% ±3.48% ±4.60%
02:43:19.569 streams/destroy.js kind='duplex' n=1000000              NA       NaN %           NA     NA     NA
02:43:19.569 streams/destroy.js kind='readable' n=1000000            NA       NaN %           NA     NA     NA
02:43:19.569 streams/destroy.js kind='transform' n=1000000           NA       NaN %           NA     NA     NA
02:43:19.569 streams/destroy.js kind='writable' n=1000000                   -0.10 %       ±4.04% ±5.37% ±6.99%
02:43:19.569 streams/pipe-object-mode.js n=5000000                  ***     15.13 %       ±2.81% ±3.73% ±4.86%
02:43:19.569 streams/pipe.js n=5000000                               NA       NaN %           NA     NA     NA
02:43:19.569 
02:43:19.569 Be aware that when doing many comparisons the risk of a false-positive
02:43:19.569 result increases. In this case, there are 10 comparisons, you can thus
02:43:19.569 expect the following amount of false-positive results:
02:43:19.569   0.50 false positives, when considering a   5% risk acceptance (*, **, ***),
02:43:19.569   0.10 false positives, when considering a   1% risk acceptance (**, ***),
02:43:19.569   0.01 false positives, when considering a 0.1% risk acceptance (***)

also it seems like there are a LOT of out of memory in the benchmark

[benjamingr]

looks like a correctness bug

[benjamingr]

Superceded by #50341