On Tue, Dec 13, 2011 at 10:12 AM, Kazu Yamamoto
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