Performance issue of slice() function

[twoeths]

Profiling from ChainSafe/lodestar#4114 shows a significant time was used for Uint8Array memory allocation

With a 5-minute profile, it takes 16% of cpu time just for this function.

This is mostly called form "slice()` function as shown in libp2p/js-libp2p#1303

[achingbrain]

@tuyennhv what sort of size of length-prefixed data are you seeing consume all this time during your profiling? Is it a few bytes on average or more like megabytes?

[twoeths]

@tuyennhv what sort of size of length-prefixed data are you seeing consume all this time during your profiling? Is it a few bytes on average or more like megabytes?

I'm not able to debug the length-prefixed data as uint8arraylist is used in different consumers, but the one thing I notice is >90% of the time slice() function spanning exactly 1 buffer and right now we do the copy of that 1 buffer unnecessarily in concat() function. If we do early return in that case (without calling concat of an array of 1 item) then I get through this issue.

In bl.slice api spec, it said that:

If the requested range spans a single internal buffer then a slice of that buffer will be returned which shares the original memory range of that Buffer. If the range spans multiple buffers then copy operations will likely occur to give you a uniform Buffer.

[achingbrain]

If we do early return in that case

This optimisation is now included in the .subarray method. It's in .subarray as that per Uint8Array semantics it should be no-copy (when possible), and not .slice as that should always be copy.

In bl.slice api spec, it said that:

bl follows semantics derived from node Buffer, this module follows semantics derived from Uint8Array which are ever-so-slightly-different-yet-also-completely-incompatible on this point.