Fumiaki Kinoshita

I think the problem really is the overhead of thread creation, not about the buffer size. fast-builder implements a rather complicated trick to avoid this issue: http://hackage.haskell.org/package/fast-builder-0.1.2.0/docs/src/Data.ByteString.FastBuilder.Internal.html#toLazyByteStringWith

A new approach based on delimited continuations seems promising: https://github.com/ghc-proposals/ghc-proposals/pull/313#issuecomment-648114538

@chessai small-bytearray-builder's design looks very interesting, but both builder and small-bytearray-builder produce fully strict byte arrays only, while we need streaming behaviour for toLazyByteString and hPutBuilder. @andrewthad I didn't know...

I added mason to bytes-builder-shootout. the latest release of mason wasn't very good in this benchmark: ``` treeToHex-2000/small-bytearray-builder mean 43.27 μs ( +- 167.3 ns ) treeToHex-2000/fast-builder mean 34.22 μs...

Unfortunately, mason's performance regressed a lot since GHC 9.2, and I didn't manage to figure out why. I decided to put the project on hold until delimited continuation primops arrives.

:+1: to the idea. I'd prefer not to add CPP pragmas whenever working on a library.

Sure, I created https://github.com/haskell/containers/pull/728

`hGetLine` from `System.IO` handles CR (http://hackage.haskell.org/package/base-4.10.0.0/docs/src/GHC.IO.Handle.Text.html#hGetLine); this discrepancy seems bad. Would it be acceptable to change the behaviour?

monoidal-containers exists and certainly a useful package, but it drags a lot of dependencies (lens, semialign, vector, unordered-containers). I think it's also beneficial to have a newtype wrapper in this...

One problem I foresee is that it would be about 10x slower, and would make the charts harder to read.