grpc_byte_buffer_reader_next() copies and references the slice. This
is not always necessary since the caller will not use the slice
after destroying the byte buffer.
A prominent example is the protobuf parser, which
calls grpc_byte_buffer_reader_next() and immediately unrefs the slice
after the call. This ref() and unref() calls can be very expensive
in the hot path.
This commit introduces grpc_byte_buffer_reader_peek() which
essentialy return a pointer to the slice in the buffer, i.e.,
no copies, and no refs.
QPS of 1MiB 1 Channel callback benchmark increases by 5%.
More importantly insructions per cycle is increased by 10%.
Also add tests and benchmarks for byte_buffer_reader_peek()
This commit reaplies 509e77a5a3
grpc_byte_buffer_reader_next() copies and references the slice. This
is not always necessary since the caller will not use the slice
after destroying the byte buffer.
A prominent example is the protobuf parser, which
calls grpc_byte_buffer_reader_next() and immediately unrefs the slice
after the call. This ref() and unref() calls can be very expensive
in the hot path.
This commit introduces grpc_byte_buffer_reader_peek() which
essentialy return a pointer to the slice in the buffer, i.e.,
no copies, and no refs.
QPS of 1MiB 1 Channel callback benchmark increases by 5%.
More importantly insructions per cycle is increased by 10%.
Also add tests and benchmarks for byte_buffer_reader_peek()
We are planning to enable -Wextra-semi flag in our project but some
header files in gRPC have extra semicolons that violates the check and
blocks us from enabling the flag.
This change removes unnecessary semicolons in the code. Note that having
semicolon after the GRPC_ABSTRACT macro technically also violates the
check, but it's fine for us since they are not used in public headers,
and it will be confusing to have lines ending only with GRPC_ABSTRACT,
so I keep them as-is.
Initializing GrpcCodegen as a global static variable
is problematic because it is possible for it to get
destructed before the last instance of `GrpcLibraryCodegen`
gets destructed and leaves the program dealing with
a dangling pointer (imagine a scenario where another
thread is using gRPC resources and the main thread
tries to join it in an object's destructor after
main ends and CoreCodegen is destructed.)
In fact, Google style guide explicitly forbids
non-trivially-destructible global variables of static
storage duration for this and other reasons and the
solution in this commit is among the recommended
workarounds referenced in
https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables
Soheil Hassas Yeganeh