History log of /5.5.2/platform/tests/pipe_test/pipe_benchmark.cc (Results 1 – 2 of 2)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v7.1.1, v7.1.0, v7.0.2, v7.0.4, v6.6.4, v6.6.5, v6.6.5-MP1, v7.0.0, v7.0.1, v6.6.1, v6.6.2, v6.5.1, v6.5.1-MP3, v6.5.1-MP5, v6.5.2, v6.6.0, v6.5.0, v6.0.3, v6.0.4, v6.0.5, v6.0.2, v5.5.4, v5.5.5, v5.5.6, v5.5.0, v5.5.1, v5.5.2, v5.5.3, v6.0.0, v6.0.1, v4.6.5, v5.1.1, v5.1.2, v5.1.3, v5.0.0, v5.0.1, v5.1.0
# 67e91cc7 03-Aug-2017 Trond Norbye <trond.norbye@gmail.com>

Add wdata() and made produced and consumed public

In order to track down the performance regression moving to
this interface try to get rid of the potential overhead from
calling through the lambda

Add wdata() and made produced and consumed public

In order to track down the performance regression moving to
this interface try to get rid of the potential overhead from
calling through the lambda methods.

The valgrind integration was removed as it wouldn't work
if the caller called wdata() and copied in data before
calling produce() as it would touch memory marked as locked.

Change-Id: I47799297c794f278cda79fd6dcb526189d19bc26
Reviewed-on: http://review.couchbase.org/81900
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Will Gardner <willg@rdner.io>

show more ...


# 2139002f 02-Aug-2017 Trond Norbye <trond.norbye@gmail.com>

Add a benchmark test for cb::Pipe

The purpose of the benchmark test is to get some numbers of the
overhead introduced by using the cb::Pipe class to keep track
of the data in the read/write buffers

Add a benchmark test for cb::Pipe

The purpose of the benchmark test is to get some numbers of the
overhead introduced by using the cb::Pipe class to keep track
of the data in the read/write buffers in the memcached core.

I've added 4 small benchmarks:

PlainMemcpy - This is the "baseline" and represent the code
it is today where we just do memcpy of the
stuff we want to insert into the buffer.

Produce - This is when we're doing the same memcpy as
above, but we're calling the produce part of
the pipe to insert the data into the buffer

Consume - This is calling the consume API to check if the
provided pointer points to the beginning to the
buffer. The memcached try to check for this
every time data is sent on the socket to check
if we need to mark the data as sent.

Rdata - Fetch the read end of the pipe to allow the client
to peak at the data.

Run on (8 X 2500 MHz CPU s)
2017-08-02 13:28:18
---------------------------------------------------
Benchmark Time CPU Iterations
---------------------------------------------------
PlainMemcpy 2 ns 2 ns 367338371
Produce 19 ns 19 ns 37031943
Consume 6 ns 6 ns 103185483
Rdata 2 ns 2 ns 292429420

Change-Id: I2fa81c93c3dc7492195cdd00020949ef577261e9
Reviewed-on: http://review.couchbase.org/81752
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...