LZ4Stream.ReadAsync needs a "low latency" mode

[judilsteve]

As per title. LZ4Stream.ReadAsync appears to read data from the input stream until either the input stream ends or there is enough uncompressed output to completely fill the provided buffer. This may be optimal for throughput in many scenarios, but it is problematic in others (e.g. network scenarios), where the caller may want to immediately read any data that can be decompressed, even if there would not be enough data to fill the provided buffer.

The current behaviour is analagous to a postal service that only delivers your letters once they have gathered enough to fill your mailbox: It may be more efficient for the postal service to do it this way, but you run the risk of your bills becoming overdue before you even receive them.

[judilsteve]

The simplest potential solution for this would be to add an overload of ReadAsync with a boolean flag that causes the function to return immediately after one call to the underlying LZ4Decoder.Decompress. However, this overload would not be used by utility functions such as Stream.CopyToAsync, so a better option might be to make this flag a constructor argument. That way, the stream can be read by third party code with the return behaviour desired by the creator.

[neuecc]

Thank you, I think it's a good suggestion.
However, the basic design is that when you want better performance or need to perform detailed handling, you should use LZ4Decoder instead of Stream.
Stream is only for interoperability, and we don't particularly recommend using it.

[judilsteve]

I've gotten around this by using the decoder API as you suggested, but there is something to be said for ergonomics: One of the main attractions of dotnet as a platform is that it tends to permit high-level abstractions like Stream.CopyToAsync() without sacrificing too much on performance.

The LZ4Stream class also suffers from an issue that is common to the built-in GzipStream and BrotliStream in System.IO.Compression: When compressing, the compression algorithm will prefer to buffer data rather than immediately compressing it and writing it to the underlying stream, as this improves compression ratio. With a NetworkStream, however, this can deadlock the entire system:

It's common in many protocols for a client to connect, send a small amount of data (a request or query of some sort), and then wait for a reply. If we try to add compression to this scenario by wrapping everything in an LZ4Stream/GzipStream/BrotliStream, the small request may not be enough to cause the compressor to flush (or it may flush most of it, but leave the last bit hanging), and since the stream stays open, the compressor has no way of knowing that the client is done sending its request, so the server never recieves the request/query, and thus the client waits indefinitely for a response that will never arrive.

[neuecc]

The recent trend in .NET is to avoid Stream.
For I/O-related operations, using PipeReader/Writer would likely be the most appropriate approach.
After all, the Stream abstraction has many flaws,
and one of them is the inability to control things as you mentioned.