| # C++ Performance Notes | |
| ## Streaming write buffering | |
| Generally, each write operation (Write(), WritesDone()) implies a syscall. | |
| gRPC will try to batch together separate write operations from different | |
| threads, but currently cannot automatically infer batching in a single stream. | |
| If message k+1 in a stream does not rely on responses from message k, it's | |
| possible to enable write batching by passing a WriteOptions argument to Write | |
| with the buffer_hint set: | |
| ~~~{.cpp} | |
| stream_writer->Write(message, WriteOptions().set_buffer_hint()); | |
| ~~~ | |
| The write will be buffered until one of the following is true: | |
| - the per-stream buffer is filled (controllable with the channel argument | |
| GRPC_ARG_HTTP2_WRITE_BUFFER_SIZE) - this prevents infinite buffering leading | |
| to OOM | |
| - a subsequent Write without buffer_hint set is posted | |
| - the call is finished for writing (WritesDone() called on the client, | |
| or Finish() called on an async server stream, or the service handler returns | |
| for a sync server stream) | |
| ## Completion Queues and Threading in the Async API | |
| Right now, the best performance trade-off is having numcpu's threads and one | |
| completion queue per thread. |