History log of /6.6.0/phosphor/ (Results 1 - 25 of 327)
Revision (<<< Hide revision tags) (Show revision tags >>>)Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
53ca1eea21-Oct-2019 Trond Norbye <trond.norbye@gmail.com>

Remove compile warnings in unit tests seen on Ubuntu 18.04

Change-Id: I58cd38aa4dbe60deeecfe0cc7c97d003c4c2efba
Reviewed-on: http://review.couchbase.org/116711
Reviewed-by: Dave Rigb

Remove compile warnings in unit tests seen on Ubuntu 18.04

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

show more ...

97c8548326-Jun-2019 Trond Norbye <trond.norbye@gmail.com>

Add support for bypass building of unit tests

Skip building unit tests if phosphor is part of
the disabled unit tests set in environment:

export COUCHBASE_DISABLED_UNIT_TESTS="k

Add support for bypass building of unit tests

Skip building unit tests if phosphor is part of
the disabled unit tests set in environment:

export COUCHBASE_DISABLED_UNIT_TESTS="kv_engine;platform;phosphor"

(This speeds up builds for others who don't modify phosphor)

Change-Id: If7b894e530189508f889df3fa20c69f3100e09ef
Reviewed-on: http://review.couchbase.org/111217
Reviewed-by: Dave Rigby <daver@couchbase.com>
Reviewed-by: Will Gardner <willg@rdner.io>
Tested-by: Build Bot <build@couchbase.com>

show more ...

20ff5ca926-Apr-2019 Dave Rigby <daver@couchbase.com>

Remove implicitly deleted chunk_iterator default ctor

As per warning on LLVM 8:

phosphor/include/phosphor/trace_buffer.h:281:13: explicitly defaulted default constructor is impl

Remove implicitly deleted chunk_iterator default ctor

As per warning on LLVM 8:

phosphor/include/phosphor/trace_buffer.h:281:13: explicitly defaulted default constructor is implicitly deleted [-Wdefaulted-function-deleted]
chunk_iterator() = default;
^
phosphor/include/phosphor/trace_buffer.h:291:32: note: default constructor of 'chunk_iterator' is implicitly deleted because field 'buffer' of reference type 'const phosphor::TraceBuffer &' would not be initialized
const TraceBuffer& buffer;

Change-Id: I42934aba729be0b48857ae24024b406b44c0ed0d
Reviewed-on: http://review.couchbase.org/108313
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@couchbase.com>

show more ...

e2feef2112-Mar-2019 Trond Norbye <trond.norbye@gmail.com>

Remove compile warning on win32 (unused variable)

Change-Id: I57483d4d5b9331661b70565bced5fd2c61c2e670
Reviewed-on: http://review.couchbase.org/106053
Reviewed-by: Dave Rigby <daver@

Remove compile warning on win32 (unused variable)

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

show more ...

499f43b203-Jan-2019 Dave Rigby <daver@couchbase.com>

MB-32016: Add 'unsanitized' variant of phosphor library

If one or more sanitizers are enabled (AddressSanitizer,
ThreadSanitizer, ...) then define an additional variant of libphosphor

MB-32016: Add 'unsanitized' variant of phosphor library

If one or more sanitizers are enabled (AddressSanitizer,
ThreadSanitizer, ...) then define an additional variant of libphosphor
which has the sanitizers /disabled/. This allows targets which
require phosphor, but which are incompatible with the sanitizers
(e.g. Erlang NIFs use platform which uses phosphor) to still be built
and run when we are building the rest of the Server with sanitizer
support.

Targets which suffer from this limitation can link against
'phosphor_unsanitized' instead of 'phosphor' to obtain a library which
doesn't use any of the sanitizers.

Change-Id: Ic758d76d5bb7969a840b615644139a277fd06a08
Reviewed-on: http://review.couchbase.org/103245
Reviewed-by: Will Gardner <willg@rdner.io>
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>

show more ...

6f2f0e8212-Aug-2018 Will Gardner <willg@rdner.io>

Add 'loop' example

The loop example simply logs the same event within a (sort of) infinite
loop. The example is useful for performing performance analysis of
phosphor to look for pot

Add 'loop' example

The loop example simply logs the same event within a (sort of) infinite
loop. The example is useful for performing performance analysis of
phosphor to look for potential bottlenecks (e.g. using perf counters).

Change-Id: I0e6662e8314e822da01d869d03018cc528afbb35
Reviewed-on: http://review.couchbase.org/98174
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>

show more ...

6c8a36a212-Aug-2018 Will Gardner <willg@rdner.io>

Correctly set TraceConfig::buffer_factory from string

When using TraceConfig::fromString the buffer factory returned
would always be the fixed trace buffer factory regardless of the

Correctly set TraceConfig::buffer_factory from string

When using TraceConfig::fromString the buffer factory returned
would always be the fixed trace buffer factory regardless of the
buffer mode. While the buffer mode member variable was being
correctly set in TraceConfig::updateFromString the buffer_factory
was not being kept in sync.

Since the dependance between the buffer mode and buffer factory is
so important (and easy to miss), to resolve this a utility class
TraceConfig::BufferFactoryContainer is introduced (ie. make it harder to
introduce the bug in the first place rather than just fix it).

In order to verify this, the TraceBuffer::bufferMode virtual member
function was added to determine the 'mode' of a buffer. The reason this
method was chosen is because TraceConfig::getBufferFactory returns a
std::function which makes determining the underlying function pointer
problematic as it would require use of type_info which behaves _very_
poorly across compilation units.

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

show more ...

61e78e5c04-Aug-2018 Will Gardner <willg@rdner.io>

De-inline the `logEvent` functions

This de-inlines/de-templates the TraceLog::logEvent
functions which drastically reduces the amount of
code generated in each compilation unit which

De-inline the `logEvent` functions

This de-inlines/de-templates the TraceLog::logEvent
functions which drastically reduces the amount of
code generated in each compilation unit which uses
a phosphor tracepoint.

This also involved adding an explicit constructor
to TraceArgument for pointer types as the types
no longer get decayed by being passing through
the logEvent function before the constructor.

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

show more ...

c687f33804-Aug-2018 Will Gardner <willg@rdner.io>

Move thread id from the TraceEvent to the TraceChunk

Following 6cfacec the support for shared chunk tenants was removed
from phosphor. Since a chunk can no longer be used by multiple

Move thread id from the TraceEvent to the TraceChunk

Following 6cfacec the support for shared chunk tenants was removed
from phosphor. Since a chunk can no longer be used by multiple
threads the thread id for a given event can be determined by the
chunk it is in. This patch makes a space optimisation by moving
the thread id to the chunk instead of the event.

This reduces the nominal size of a TraceEvent object from 44 bytes
to 40 bytes (due to alignment this is actually a reduction from
48 bytes).

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

show more ...

d380e59b04-Aug-2018 Will Gardner <willg@rdner.io>

Store event and argument types in the TPI instead of TraceEvent

Event type and argument types _should_ be static for a given
tracepoint (since C++ is a statically typed language..) so th

Store event and argument types in the TPI instead of TraceEvent

Event type and argument types _should_ be static for a given
tracepoint (since C++ is a statically typed language..) so this
reflects this in a space optimisation by moving those type
enums from the TraceEvent object to the tracepoint_info object.

This brings the nominal size of a TraceEvent from 47 bytes to
44 bytes (although this is still effectively 48 bytes due to
alignment).

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

show more ...

d92caa4f03-Aug-2018 Will Gardner <willg@rdner.io>

Remove superfluous TraceLog::logEvent variants

Due to internal macro changes, various logEvent variants are no
longer necessary.

Change-Id: I4a54d59722929f90ffdc3a666f5dde0d9bcf

Remove superfluous TraceLog::logEvent variants

Due to internal macro changes, various logEvent variants are no
longer necessary.

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

show more ...

f8c091a603-Aug-2018 Will Gardner <willg@rdner.io>

Refactor internal trace macro logic

This code makes some subtle internal changes to the way trace
macros are processed internally in order to:

- Make argument orders more consis

Refactor internal trace macro logic

This code makes some subtle internal changes to the way trace
macros are processed internally in order to:

- Make argument orders more consistent
- Always supply an event type to the internal macro (even when
currently unnecessary)
- Avoid variadic macros internally (so that arguments can be
addressed directly)

This is to reduce code churn in future changes moving the event
type and argument types into the TPI from the TraceEvent object.

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

show more ...

26aa9a8b03-Aug-2018 Will Gardner <willg@rdner.io>

Remove user-facing variadic trace macros

The user-facing variadic trace macros (ie. the non-numbered
macros) have been semi-deprecated for a while due to their
inability to support n

Remove user-facing variadic trace macros

The user-facing variadic trace macros (ie. the non-numbered
macros) have been semi-deprecated for a while due to their
inability to support named arguments. They additionally
pose a barrier to potential optimisations so this commit
removes them.

Change-Id: If4bbea57e5fe16149b51243649ec6f26724f6ff8
Reviewed-on: http://review.couchbase.org/97827
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Paolo Cocchi <paolo.cocchi@couchbase.com>

show more ...

9365bbbb03-Aug-2018 Will Gardner <willg@rdner.io>

Allow for updating a TraceConfig from a config string

This is a minor refactor which separates the parsing and updating
logic from `TraceConfig::fromString` into its own function in

Allow for updating a TraceConfig from a config string

This is a minor refactor which separates the parsing and updating
logic from `TraceConfig::fromString` into its own function in
`TraceConfig::updateFromString` which allows a pre-existing
TraceConfig object to be updated from a config string.

This may be useful in a situation where the same config is to be
used with only minor adjustments (e.g. with only log size changed
but the same categories used).

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

show more ...

ff39195703-Aug-2018 Will Gardner <willg@rdner.io>

[Standalone Build] Fastforward tlm submodule

The standalone builds were broken due to same CMake changes which
meant the C++ settings weren't getting pulled in (e.g. tried to
compile

[Standalone Build] Fastforward tlm submodule

The standalone builds were broken due to same CMake changes which
meant the C++ settings weren't getting pulled in (e.g. tried to
compiled as C++03).

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

show more ...

5b7b00a803-Aug-2018 Christopher Farman <christopher.farman@couchbase.com>

MB-30379: Catch empty values in set trace.config

Add an exception throw when the values given, during a set trace.config
command in mcctl, do not follow the key:value format. This stops

MB-30379: Catch empty values in set trace.config

Add an exception throw when the values given, during a set trace.config
command in mcctl, do not follow the key:value format. This stops a
logic error that caused the connection to be reset by peer.

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

show more ...

b3d40ebe11-Jun-2018 Trond Norbye <trond.norbye@gmail.com>

Move CMake minimum version forward to 3.2

We don't _need_ any new functionality from 3.2, but it is
desired to move it up to the same version as our top level
cmake file to avoid fal

Move CMake minimum version forward to 3.2

We don't _need_ any new functionality from 3.2, but it is
desired to move it up to the same version as our top level
cmake file to avoid falling behind on cmake version (and
get a bigger task the next time we want to upgrade for some
reason)

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

show more ...

Revision tags: v5.5.0
96501c5701-Jun-2018 Dave Rigby <daver@couchbase.com>

Add category_onoff_bench

Add a new benchmark suite which measures the cost of enabling /
disabling trace events via the category feature.

Includes test varints for basic TRACE_E

Add category_onoff_bench

Add a new benchmark suite which measures the cost of enabling /
disabling trace events via the category feature.

Includes test varints for basic TRACE_EVENT0 macro, along with
TRACE_LOCKGUARD_TIMED.

Example output:

Run on (24 X 1222.46 MHz CPU s)
2018-06-01 09:30:30
------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
------------------------------------------------------------------------------------------
CategoryOnOffBench/Macro/1 114 ns 114 ns 4938250
CategoryOnOffBench/Macro/0 7 ns 7 ns 107491918
CategoryOnOffBench/Macro/1/threads:24 9 ns 203 ns 2718312
CategoryOnOffBench/Macro/0/threads:24 1 ns 11 ns 69343896
CategoryOnOffBench/LockguardTimedFast/1 117 ns 117 ns 5971601
CategoryOnOffBench/LockguardTimedFast/0 35 ns 35 ns 20201763
CategoryOnOffBench/LockguardTimedFast/1/threads:24 11 ns 237 ns 2367048
CategoryOnOffBench/LockguardTimedFast/0/threads:24 2 ns 52 ns 11621904
CategoryOnOffBench/LockguardTimedSlow/1 215 ns 215 ns 3150389
CategoryOnOffBench/LockguardTimedSlow/0 35 ns 35 ns 20142427
CategoryOnOffBench/LockguardTimedSlow/1/threads:24 19 ns 432 ns 1325832
CategoryOnOffBench/LockguardTimedSlow/0/threads:24 3 ns 55 ns 13389768
LockGuardBaseline 30 ns 30 ns 23235754
LockGuardBaseline/threads:24 2 ns 55 ns 10051872
NullBench 3 ns 3 ns 240751619
NullBench/threads:24 0 ns 4 ns 160179696

This demonstrates that all three macro variants tested (TRACE_EVENT0;
TRACE_LOCKGUARD_TIMED with fast and slow lock) have minimal overhead
when the macro is disabled.

- compare TRACE_EVENT0 to NullBench (which just measures benchmark
overhead). Single-threaded/multi-threaded:

------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
------------------------------------------------------------------------------------------
CategoryOnOffBench/Macro/0 7 ns 7 ns 107491918
NullBench 3 ns 3 ns 240751619

CategoryOnOffBench/Macro/0/threads:24 1 ns 11 ns 69343896
NullBench/threads:24 0 ns 4 ns 160179696

- compare TRACE_LOCKGUARD_TIMED fast/slow to LockGuardBaseline (which
measures mutex lock/unlock cost) - lock()/unlock() is most of the
cost. Single-threaded/multi-threaded:

CategoryOnOffBench/LockguardTimedFast/0 35 ns 35 ns 20201763
CategoryOnOffBench/LockguardTimedSlow/0 35 ns 35 ns 20142427
LockGuardBaseline 30 ns 30 ns 23235754

CategoryOnOffBench/LockguardTimedFast/0/threads:24 2 ns 53 ns 11450304
CategoryOnOffBench/LockguardTimedSlow/0/threads:24 2 ns 56 ns 13618128
LockGuardBaseline/threads:24 2 ns 56 ns 10606656

We can also see the cost of LockguardTimed (when enabled) over a
vanilla lock guard - the cost of the mutex lock/unlock increases by
~4x in both single and multi-threaded configs:

------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
------------------------------------------------------------------------------------------
CategoryOnOffBench/LockguardTimedFast/1 117 ns 117 ns 5971601
LockGuardBaseline 30 ns 30 ns 23235754

CategoryOnOffBench/LockguardTimedFast/1/threads:24 11 ns 237 ns 2367048
LockGuardBaseline/threads:24 2 ns 55 ns 10051872

Finally, we can also see the cost of "fast" vs. "slow" locks - when we
actually need to add 3x trace event macros to the log file; this adds
~100ns compared to the cost of performing the timing.

Note however that we'd typically consider a lock to only be "slow" if
it exceeded some number of milliseconds; so the cost of an extra 100ns
is negligible.

------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
------------------------------------------------------------------------------------------
CategoryOnOffBench/LockguardTimedFast/1 117 ns 117 ns 5971601
CategoryOnOffBench/LockguardTimedSlow/1 215 ns 215 ns 3150389
LockGuardBaseline 30 ns 30 ns 23235754

CategoryOnOffBench/LockguardTimedFast/1/threads:24 11 ns 237 ns 2367048
CategoryOnOffBench/LockguardTimedSlow/1/threads:24 19 ns 432 ns 1325832
LockGuardBaseline/threads:24 2 ns 55 ns 10051872

Change-Id: I8c0ba6126d606edeb3b02a6103724c063832413a
Reviewed-on: http://review.couchbase.org/95014
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Tim Bradgate <tim.bradgate@couchbase.com>
Reviewed-by: Will Gardner <willg@rdner.io>

show more ...

5dfc7d2212-May-2018 Dave Rigby <daver@couchbase.com>

Ensure TRACE_LOCKGUARD{,_TIMED} locks mutex even when disabled

Unlike all other Phosphor macros, TRACE_LOCKGUARD{,_TIMED} have a
side-effect - they lock & unlock the given mutex. As such

Ensure TRACE_LOCKGUARD{,_TIMED} locks mutex even when disabled

Unlike all other Phosphor macros, TRACE_LOCKGUARD{,_TIMED} have a
side-effect - they lock & unlock the given mutex. As such, when
phosphor is compiled out they need to still perform this operation.

Fix this; and add a unit test for the expected behaviour.

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

show more ...

2792c70e11-May-2018 Dave Rigby <daver@couchbase.com>

Define TRACE_LOCKGUARD_TIMED even when Phosphor disabled

This fixes a build break if callers try to use the new
TRACE_LOCKGUARD_TIMED but phosphor is compiled-out.

Change-Id: I2

Define TRACE_LOCKGUARD_TIMED even when Phosphor disabled

This fixes a build break if callers try to use the new
TRACE_LOCKGUARD_TIMED but phosphor is compiled-out.

Change-Id: I2cfa1cf138717da4fb13a713f7a4e9e729176159
Reviewed-on: http://review.couchbase.org/94079
Reviewed-by: Dave Rigby <daver@couchbase.com>
Tested-by: Dave Rigby <daver@couchbase.com>

show more ...

39206c2e08-May-2018 Dave Rigby <daver@couchbase.com>

Add timed lockguard support

Add support for recording mutex wait and held times; but *only* if
either time exceeds a given threshold.

Identifying mutex contention (where one thr

Add timed lockguard support

Add support for recording mutex wait and held times; but *only* if
either time exceeds a given threshold.

Identifying mutex contention (where one thread is waiting a long time)
is extremely useful in tracking down performance issues, however the
median times are typically fast, and so if we logged events for all
mutex locks we'd quickly consume the whole trace log. Instead, if we
only record trace events for locks which are slower than some limit,
we can discount much of the "noise" and focus on the signal.

This patch also renames "lock.acquire" to "lock.wait" as IMHO that's a
clearer (and more concise) name for that the span represents.

Note that care must still be taken in using these macros, as each one
requires 3x calls to steady_clock::now(); even if no trace_event is
recorded. As such, consider adding to a non-default category, and only
enabling on-demand.

Change-Id: I4884cd8a2e4381ab16fb9ecfab0478546d52f0ef
Reviewed-on: http://review.couchbase.org/93889
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...

c00373e208-May-2018 Dave Rigby <daver@couchbase.com>

Use Complete event type for LOCKGUARD events

Change the implementation of TRACE_LOCKGUARD to use 2x Complete
events, instead of the previous 2x SyncStart, 2x SyncEnd events.

Cha

Use Complete event type for LOCKGUARD events

Change the implementation of TRACE_LOCKGUARD to use 2x Complete
events, instead of the previous 2x SyncStart, 2x SyncEnd events.

Change-Id: I532d68413417da65d773a210b201fb06d94c6c22
Reviewed-on: http://review.couchbase.org/93886
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>

show more ...

195e116e08-May-2018 Dave Rigby <daver@couchbase.com>

Use Complete event type for scoped events

Use the new Complete trace type to implement the scoped (TRACE_EVENT*
/ TRACE_FUNCTION*) event macros. This reduces the number of TraceEvent

Use Complete event type for scoped events

Use the new Complete trace type to implement the scoped (TRACE_EVENT*
/ TRACE_FUNCTION*) event macros. This reduces the number of TraceEvent
objects needed for these events by half; well worth the modest (1
word) increase in size to support Complete events (needed to add 64bit
duration field).

Implemented by adding a RAII-style ScopedEventGuard class; which
captures the arguments for a trace event, and if enabled logs the
event in it's destructor.

Note this change required the removal of the TRACE_EVENT() (varargs)
macro; as we now need to capture the types of the args (as the call to
logEvent() happens at the end of the scope).

Change-Id: I975927385616887a26ea8f894a1d06c08e322ecf
Reviewed-on: http://review.couchbase.org/93879
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Tim Bradgate <tim.bradgate@couchbase.com>

show more ...

cfd8018409-May-2018 Dave Rigby <daver@couchbase.com>

TracingOnOffMacro: Change macro to TRACE_EVENT

Change from the 'instant' event macro to the scoped event macro; as
this is much more commonly used and hence more representative.

TracingOnOffMacro: Change macro to TRACE_EVENT

Change from the 'instant' event macro to the scoped event macro; as
this is much more commonly used and hence more representative.

Change-Id: I4d4f3a9a192b6ae0ccbc44a021631c9dc9422b09
Reviewed-on: http://review.couchbase.org/93919
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>

show more ...

cd65876008-May-2018 Dave Rigby <daver@couchbase.com>

Introduce Complete event type

Add a new event type which logically combines a pair of SyncStart and
SyncEnd events into a single 'Complete' event.

In a trace that most of the ev

Introduce Complete event type

Add a new event type which logically combines a pair of SyncStart and
SyncEnd events into a single 'Complete' event.

In a trace that most of the events are duration events, using complete
events to replace the duration events can reduce the size of the trace
to about half.

This patch adds Complete events to the core of Phosphor; exposing them
via new TRACE_EVENT_COMPLETE* macros.

Change-Id: Ib445ea37d58ed5fb5f6b690c9c31d19337a09c56
Reviewed-on: http://review.couchbase.org/93877
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>

show more ...

12345678910>>...14