[web-devel] ResponseEnumerator

[Michael Snoyman]

On Tue, Dec 13, 2011 at 10:12 AM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:
> Hello Michael,
>
> Thank you for your answer.
>
>> Q1. Shouldn't it be at the user's discretion to use Builders
>> internally and then create a stream of ByteStrings?
>> A1. That would be less efficient, as we wouldn't get cheap
>> concatenation with the response headers.
>
> But I guess response headers can be sent by sendMany (i.e. writev())
> without concatenation. And if a response body is created, for example,
> by enumHandle, the ByteString is large enough. (ByteStrings for a
> response body are not concatenated at all, I believe.) So, I'm not
> convinced with your answer.

writev might make the different here, I'm not sure. I haven't done any
performance testing on the difference between writev with a number of
smaller ByteStrings versus a single larger ByteString. That would be
an interesting distinction.

But I suppose there's also a A1b answer. The only downside it seems of
using Builder versus ByteString is the extra typing a user needs in
order to convert to Builders. If we switch to ByteString, it may be
true that we can achieve the same performance of Builders (based on
the question of writev performance above), but it would require extra
thought from a user to ensure that they properly concatenate their
Builders. In this case, I would not expect writev to have the same
performance, as the ByteStrings are likely coming through in different
chunks.

> I'm not objecting your design. Rather, I would learn reasons of
> your design choice.
>
> Suppose that Builder is more efficient than ByteString in some cases.
> Even in this case, it seems to me that the iteratee can be defined as
> "Iteratee ByteString IO a" and the iteratee translates ByteString to
> Builder (and to ByteString) inside. This design lets programms to omit
> "map fromByteString" (e.g. in your Proxy code).

Michael