Ruby's `require_relative` method currently converts paths to absolute
paths. This idiosyncrasy means that the implementation of the require
for the distributed shared library works, however the semantics do not
mesh with the semantics of `require_relative`.
This is an issue when you redefine `require_relative` and follow the
semantics of the method, as [derailed_benchmarks does][1]. This means
that any project that uses `grpc` also cannot use that project (which
I will also be patching).
In the event that a new version of Ruby follows the semantics of the
method (whether or not that is likely), this will break as well.
By switching to `require` here instead of `require_relative`, we
maintain the functionality but do not use a semantically incompatible
method to do so.
[1]: 1b0c425720/lib/derailed_benchmarks/core_ext/kernel_require.rb (L24-L27)
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