Flush is expensive generally, and in a scenario where a controller returns a single POJO that Spring renders via a HttpMessageConverter we end up with a double flush - once at the end of the message writer, and once implicitly when the container finishes processing the response. The containers are optimized not to flush if their buffer is empty, but in the case that there are still headers waiting to be flushed (e.g. trailer headers), this ends up almost doubling the cost of request processing. I tried it with a modified message writer (copied all of AbstractGenericHttpMessageConverter and commented out the call to flush) and saw the benefit immediately.

I guess we might have to just flush if we think it might be streaming (i.e. the controller returns a Publisher), even though it still might be inefficient to flush after every message, because whether or not we could improve performance depends on how often they are emitted.