Client-side streaming works slowly when spam with small messages.

        for (uint64_t i = 0; i < mCalls - 1; ++i) {
            request.setPing(i);
            stream->writeMessage(request);
        }

The above code consumes lot of time especially if the mCalls number is huge.

The flame graph tst_bench_qtgrpcclient_dwarf_client_stream.svg shows that we spend lot of time on internal event queue locks. This happens because of frequent calls of the QNonContiguousByteDevice::deleteLater.

It's indeed should be optimized. The current proposal is to use of the different QHttp2Stream::sendDATA signature and control the QNonContiguousByteDevice lifetime from the QGrpcHttp2Channel side, but not leave this to QHttp2Stream internal logic. The re-usability of the QNonContiguousByteDevice* is questionable(most probably we still need to delete it after completing the sendDATA call, but we at least may try to clear its memory directly but not by using the deleteLater.