You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In streamingUpload, a new buffer is allocated for every chunk in the call to finaliseS. A better idea might be to allocate one buffer and reuse it - at the moment there shouldn't be any possibility of concurrent access to the buffer between different requests.
Taking this one step further, instead of using the S abstraction, we could write directly into this shared buffer when each ByteString is received. This would mean needing to be very careful about ordering so we don't start writing the next chunk into the buffer before sending it, but I think that should be handled by yield passing the chunk to be sent before the conduit continues.
The text was updated successfully, but these errors were encountered:
I would also be interested in concurrent uploads, even when drawing from a stream. Buffering N×chunksize blocks of memory doesn't seem that bad, but getting concurrent uploads and reused buffers right at the same time could be really hard.
In
streamingUpload
, a new buffer is allocated for every chunk in the call tofinaliseS
. A better idea might be to allocate one buffer and reuse it - at the moment there shouldn't be any possibility of concurrent access to the buffer between different requests.Taking this one step further, instead of using the
S
abstraction, we could write directly into this shared buffer when eachByteString
is received. This would mean needing to be very careful about ordering so we don't start writing the next chunk into the buffer before sending it, but I think that should be handled byyield
passing the chunk to be sent before the conduit continues.The text was updated successfully, but these errors were encountered: