snapframework/snap-core — comment on commit 53b8d6c3defa6214067696b59536e877db7295a6
File:  line 0
By meiersi:

Hi Gregory,

no problem. You are right about the benchmarking. This has to be done. In general, I expect that going for the smallest possible size that is sufficient to amortize the chunk boundary processing overhead is what we want to do. This gives good latency (and perhaps even better cache usage) and small memory requirements per connection. I do not yet know what the exact number is.

The "setting it slightly smaller than 4kb" is important, as it ensures that no pinned memory is wasted because the pinned memory is allocated in blocks, which are currently of size 4kb (see [rts/Constants.h](http://hackage.haskell.org/trac/ghc/browser/includes/rts/Constants.h#L137) and the corresponding [commentary](http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/BlockAlloc)). I do not yet know the exact reasoning behind the [chunkOverhead](https://github.com/meiersi/bytestring/blob/master/Data/ByteString/Lazy/Internal.hs#L121) computation. I guess Johan could explain it.

best regards,
Simon