@@ -392,7 +392,7 @@ putFloat64le = putArrayBuffer <=< encodeFloat64le
392392-- | * *O(1)* monoid append
393393-- | * *O(n)* fold
394394-- |
395−-- | Our `Builder` monoid implementation is an unbalanced binary tree.
395+-- | Our `Builder` implementation is an unbalanced binary tree.
396396-- |
397397-- | For monoid `append`, what we actually get is *O(1)* when either the
398398-- | left or right tree is a singleton. If that's not true, then in the
@@ -439,8 +439,7 @@ putFloat64le = putArrayBuffer <=< encodeFloat64le
439439-- |
440440-- | We hope that this implementation is fairly fast, but we
441441-- | haven't chosen this implementation because it's fast, we've chosen
442−-- | this implementation because it's simple. This library provides basic
443−-- | ArrayBuffer serialization with the familar “put monad” style.
442+-- | this implementation because it's simple.
444443-- | The only currently existing Purescript libary which does ArrayBuffer
445444-- | serialization is
446445-- | https://pursuit.purescript.org/packages/purescript-arraybuffer-class
@@ -451,4 +450,14 @@ putFloat64le = putArrayBuffer <=< encodeFloat64le
451450-- | one is fast.
452451-- |
453452-- | One relatively cheap and simple performance improvement for this library would be to
454−-- | remove the Null constructor of `Builder` and instead use Javascript nulls.
453+-- | remove the Null constructor of `Builder` and instead use Javascript nulls.
454+-- |
455+-- | In the longer term, it might make sense to try to change the Builder so
456+-- | that it works like the
457+-- | https://hackage.haskell.org/package/bytestring/docs/Data-ByteString-Builder.html
458+-- |
459+-- | Here are some benchmarks of different Haskell ByteString builders
460+-- | https://github.com/haskell-perf/strict-bytestring-builders
461+-- |
462+-- | We've tried to design the API for this library with minimal assumptions,
463+-- | so that if we want to change the Builder implementation later then we can.