[improvement] Avoid trace ID and span allocations when not observing by schlosna · Pull Request #168 · palantir/tracing-java

schlosna · 2019-06-06T21:39:31Z

Before this PR

Related to #167 there is a lot of memory allocation, garbage collection overhead, and CPU overhead of random ID generation for trace IDs and spans when traces are not observable (i.e. either not explicitly defined as observable or not selected for sampling).

After this PR

Avoid creating spans when the containing trace is not observable and lazily generate trace IDs only for observable traces to avoid the memory allocation, garbage collection overhead, and CPU overhead of random generation.

Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

iamdanfox · 2019-06-07T12:17:26Z

+ return NOOP;
+ }
+
 Trace(boolean isObservable, String traceId) {


Wanna mark this @VisibleForTesting and make DeferredTracer call your new static create method?

carterkozak · 2019-06-07T12:21:09Z

+ return new Trace(isObservable, traceId.toString());
+ }
+ return NOOP;
+ }


I think we still need to generate random trace IDs for non-observable traces, since the ID is applied to requests and logging MDC allowing us to load all the logs for an operation across services, even when the operation has not been sampled.
Fortunately traces are relatively uncommon, spans are created significantly more frequently, and the span ids are unimportant for unsampled traces.

Mmm good point, setTrace will always call MDC.put(Tracers.TRACE_ID_KEY, trace.getTraceId());, and we really do want those traceIds so we can correlate logs properly.

yeah, probably need to remove the lazyTraceId then as there isn't a benefit if we're immediately going to generate the String form for MDC.

It may still be helpful for span IDs, which iirc use the same function. If we have 500 spans per trace, that may provide a sizable improvement.

iamdanfox · 2019-06-07T12:24:17Z

 */
 public final class Trace {

+ private static final Trace NOOP = new Trace(false, "noop");


Could we put a one-liner of javadoc on this guy to say that we just re-use this single instance for all non-observable traces?

carterkozak · 2019-06-14T19:27:37Z

I think we still need to track span depth for non-sampled traces. When the root span is completed via Tracer.completeSpan/fastCompleteSpan the trace thread state is removed, along with the traceId MDC value. An approach I've considered is to use a different data type for sampled and unsampled traces, where unsampled traces have a traceId and a counter in place of the stack of spans. when the counter is decremented to zero, we can remove thread state.

schlosna · 2019-06-20T19:23:56Z

closing in favor of #180

schlosna · 2019-06-06T21:39:31Z

Before this PR

Related to #167 there is a lot of memory allocation, garbage collection overhead, and CPU overhead of random ID generation for trace IDs and spans when traces are not observable (i.e. either not explicitly defined as observable or not selected for sampling).

After this PR

Avoid creating spans when the containing trace is not observable and lazily generate trace IDs only for observable traces to avoid the memory allocation, garbage collection overhead, and CPU overhead of random generation.

Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

iamdanfox · 2019-06-07T12:17:26Z

+ return NOOP;
+ }
+
 Trace(boolean isObservable, String traceId) {


Wanna mark this @VisibleForTesting and make DeferredTracer call your new static create method?

carterkozak · 2019-06-07T12:21:09Z

+ return new Trace(isObservable, traceId.toString());
+ }
+ return NOOP;
+ }


I think we still need to generate random trace IDs for non-observable traces, since the ID is applied to requests and logging MDC allowing us to load all the logs for an operation across services, even when the operation has not been sampled.
Fortunately traces are relatively uncommon, spans are created significantly more frequently, and the span ids are unimportant for unsampled traces.

Mmm good point, setTrace will always call MDC.put(Tracers.TRACE_ID_KEY, trace.getTraceId());, and we really do want those traceIds so we can correlate logs properly.

yeah, probably need to remove the lazyTraceId then as there isn't a benefit if we're immediately going to generate the String form for MDC.

It may still be helpful for span IDs, which iirc use the same function. If we have 500 spans per trace, that may provide a sizable improvement.

iamdanfox · 2019-06-07T12:24:17Z

 */
 public final class Trace {

+ private static final Trace NOOP = new Trace(false, "noop");


Could we put a one-liner of javadoc on this guy to say that we just re-use this single instance for all non-observable traces?

carterkozak · 2019-06-14T19:27:37Z

I think we still need to track span depth for non-sampled traces. When the root span is completed via Tracer.completeSpan/fastCompleteSpan the trace thread state is removed, along with the traceId MDC value. An approach I've considered is to use a different data type for sampled and unsampled traces, where unsampled traces have a traceId and a counter in place of the stack of spans. when the counter is decremented to zero, we can remove thread state.

schlosna · 2019-06-20T19:23:56Z

closing in favor of #180

schlosna · 2019-06-06T21:39:31Z

Before this PR

Related to #167 there is a lot of memory allocation, garbage collection overhead, and CPU overhead of random ID generation for trace IDs and spans when traces are not observable (i.e. either not explicitly defined as observable or not selected for sampling).

After this PR

Avoid creating spans when the containing trace is not observable and lazily generate trace IDs only for observable traces to avoid the memory allocation, garbage collection overhead, and CPU overhead of random generation.

Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

iamdanfox · 2019-06-07T12:17:26Z

+ return NOOP;
+ }
+
 Trace(boolean isObservable, String traceId) {


Wanna mark this @VisibleForTesting and make DeferredTracer call your new static create method?

carterkozak · 2019-06-07T12:21:09Z

+ return new Trace(isObservable, traceId.toString());
+ }
+ return NOOP;
+ }


I think we still need to generate random trace IDs for non-observable traces, since the ID is applied to requests and logging MDC allowing us to load all the logs for an operation across services, even when the operation has not been sampled.
Fortunately traces are relatively uncommon, spans are created significantly more frequently, and the span ids are unimportant for unsampled traces.

Mmm good point, setTrace will always call MDC.put(Tracers.TRACE_ID_KEY, trace.getTraceId());, and we really do want those traceIds so we can correlate logs properly.

yeah, probably need to remove the lazyTraceId then as there isn't a benefit if we're immediately going to generate the String form for MDC.

It may still be helpful for span IDs, which iirc use the same function. If we have 500 spans per trace, that may provide a sizable improvement.

iamdanfox · 2019-06-07T12:24:17Z

 */
 public final class Trace {

+ private static final Trace NOOP = new Trace(false, "noop");


Could we put a one-liner of javadoc on this guy to say that we just re-use this single instance for all non-observable traces?

carterkozak · 2019-06-14T19:27:37Z

I think we still need to track span depth for non-sampled traces. When the root span is completed via Tracer.completeSpan/fastCompleteSpan the trace thread state is removed, along with the traceId MDC value. An approach I've considered is to use a different data type for sampled and unsampled traces, where unsampled traces have a traceId and a counter in place of the stack of spans. when the counter is decremented to zero, we can remove thread state.

schlosna · 2019-06-20T19:23:56Z

closing in favor of #180

schlosna · 2019-06-06T21:39:31Z

Before this PR

Related to #167 there is a lot of memory allocation, garbage collection overhead, and CPU overhead of random ID generation for trace IDs and spans when traces are not observable (i.e. either not explicitly defined as observable or not selected for sampling).

After this PR

Avoid creating spans when the containing trace is not observable and lazily generate trace IDs only for observable traces to avoid the memory allocation, garbage collection overhead, and CPU overhead of random generation.

Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

iamdanfox · 2019-06-07T12:17:26Z

+ return NOOP;
+ }
+
 Trace(boolean isObservable, String traceId) {


Wanna mark this @VisibleForTesting and make DeferredTracer call your new static create method?

carterkozak · 2019-06-07T12:21:09Z

+ return new Trace(isObservable, traceId.toString());
+ }
+ return NOOP;
+ }


I think we still need to generate random trace IDs for non-observable traces, since the ID is applied to requests and logging MDC allowing us to load all the logs for an operation across services, even when the operation has not been sampled.
Fortunately traces are relatively uncommon, spans are created significantly more frequently, and the span ids are unimportant for unsampled traces.

Mmm good point, setTrace will always call MDC.put(Tracers.TRACE_ID_KEY, trace.getTraceId());, and we really do want those traceIds so we can correlate logs properly.

yeah, probably need to remove the lazyTraceId then as there isn't a benefit if we're immediately going to generate the String form for MDC.

It may still be helpful for span IDs, which iirc use the same function. If we have 500 spans per trace, that may provide a sizable improvement.

iamdanfox · 2019-06-07T12:24:17Z

 */
 public final class Trace {

+ private static final Trace NOOP = new Trace(false, "noop");


Could we put a one-liner of javadoc on this guy to say that we just re-use this single instance for all non-observable traces?

carterkozak · 2019-06-14T19:27:37Z

I think we still need to track span depth for non-sampled traces. When the root span is completed via Tracer.completeSpan/fastCompleteSpan the trace thread state is removed, along with the traceId MDC value. An approach I've considered is to use a different data type for sampled and unsampled traces, where unsampled traces have a traceId and a counter in place of the stack of spans. when the counter is decremented to zero, we can remove thread state.

schlosna · 2019-06-20T19:23:56Z

closing in favor of #180

schlosna · 2019-06-06T21:39:31Z

Before this PR

Related to #167 there is a lot of memory allocation, garbage collection overhead, and CPU overhead of random ID generation for trace IDs and spans when traces are not observable (i.e. either not explicitly defined as observable or not selected for sampling).

After this PR

Avoid creating spans when the containing trace is not observable and lazily generate trace IDs only for observable traces to avoid the memory allocation, garbage collection overhead, and CPU overhead of random generation.

Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

iamdanfox · 2019-06-07T12:17:26Z

+ return NOOP;
+ }
+
 Trace(boolean isObservable, String traceId) {


Wanna mark this @VisibleForTesting and make DeferredTracer call your new static create method?

carterkozak · 2019-06-07T12:21:09Z

+ return new Trace(isObservable, traceId.toString());
+ }
+ return NOOP;
+ }


I think we still need to generate random trace IDs for non-observable traces, since the ID is applied to requests and logging MDC allowing us to load all the logs for an operation across services, even when the operation has not been sampled.
Fortunately traces are relatively uncommon, spans are created significantly more frequently, and the span ids are unimportant for unsampled traces.

Mmm good point, setTrace will always call MDC.put(Tracers.TRACE_ID_KEY, trace.getTraceId());, and we really do want those traceIds so we can correlate logs properly.

yeah, probably need to remove the lazyTraceId then as there isn't a benefit if we're immediately going to generate the String form for MDC.

It may still be helpful for span IDs, which iirc use the same function. If we have 500 spans per trace, that may provide a sizable improvement.

iamdanfox · 2019-06-07T12:24:17Z

 */
 public final class Trace {

+ private static final Trace NOOP = new Trace(false, "noop");


Could we put a one-liner of javadoc on this guy to say that we just re-use this single instance for all non-observable traces?

carterkozak · 2019-06-14T19:27:37Z

I think we still need to track span depth for non-sampled traces. When the root span is completed via Tracer.completeSpan/fastCompleteSpan the trace thread state is removed, along with the traceId MDC value. An approach I've considered is to use a different data type for sampled and unsampled traces, where unsampled traces have a traceId and a counter in place of the stack of spans. when the counter is decremented to zero, we can remove thread state.

schlosna · 2019-06-20T19:23:56Z

closing in favor of #180

schlosna · 2019-06-06T21:39:31Z

Before this PR

Related to #167 there is a lot of memory allocation, garbage collection overhead, and CPU overhead of random ID generation for trace IDs and spans when traces are not observable (i.e. either not explicitly defined as observable or not selected for sampling).

After this PR

Avoid creating spans when the containing trace is not observable and lazily generate trace IDs only for observable traces to avoid the memory allocation, garbage collection overhead, and CPU overhead of random generation.

Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

iamdanfox · 2019-06-07T12:17:26Z

+ return NOOP;
+ }
+
 Trace(boolean isObservable, String traceId) {


Wanna mark this @VisibleForTesting and make DeferredTracer call your new static create method?

carterkozak · 2019-06-07T12:21:09Z

+ return new Trace(isObservable, traceId.toString());
+ }
+ return NOOP;
+ }


I think we still need to generate random trace IDs for non-observable traces, since the ID is applied to requests and logging MDC allowing us to load all the logs for an operation across services, even when the operation has not been sampled.
Fortunately traces are relatively uncommon, spans are created significantly more frequently, and the span ids are unimportant for unsampled traces.

Mmm good point, setTrace will always call MDC.put(Tracers.TRACE_ID_KEY, trace.getTraceId());, and we really do want those traceIds so we can correlate logs properly.

yeah, probably need to remove the lazyTraceId then as there isn't a benefit if we're immediately going to generate the String form for MDC.

It may still be helpful for span IDs, which iirc use the same function. If we have 500 spans per trace, that may provide a sizable improvement.

iamdanfox · 2019-06-07T12:24:17Z

 */
 public final class Trace {

+ private static final Trace NOOP = new Trace(false, "noop");


Could we put a one-liner of javadoc on this guy to say that we just re-use this single instance for all non-observable traces?

carterkozak · 2019-06-14T19:27:37Z

I think we still need to track span depth for non-sampled traces. When the root span is completed via Tracer.completeSpan/fastCompleteSpan the trace thread state is removed, along with the traceId MDC value. An approach I've considered is to use a different data type for sampled and unsampled traces, where unsampled traces have a traceId and a counter in place of the stack of spans. when the counter is decremented to zero, we can remove thread state.

schlosna · 2019-06-20T19:23:56Z

closing in favor of #180

schlosna · 2019-06-06T21:39:31Z

Before this PR

Related to #167 there is a lot of memory allocation, garbage collection overhead, and CPU overhead of random ID generation for trace IDs and spans when traces are not observable (i.e. either not explicitly defined as observable or not selected for sampling).

After this PR

Avoid creating spans when the containing trace is not observable and lazily generate trace IDs only for observable traces to avoid the memory allocation, garbage collection overhead, and CPU overhead of random generation.

Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

iamdanfox · 2019-06-07T12:17:26Z

+ return NOOP;
+ }
+
 Trace(boolean isObservable, String traceId) {


Wanna mark this @VisibleForTesting and make DeferredTracer call your new static create method?

carterkozak · 2019-06-07T12:21:09Z

+ return new Trace(isObservable, traceId.toString());
+ }
+ return NOOP;
+ }


I think we still need to generate random trace IDs for non-observable traces, since the ID is applied to requests and logging MDC allowing us to load all the logs for an operation across services, even when the operation has not been sampled.
Fortunately traces are relatively uncommon, spans are created significantly more frequently, and the span ids are unimportant for unsampled traces.

Mmm good point, setTrace will always call MDC.put(Tracers.TRACE_ID_KEY, trace.getTraceId());, and we really do want those traceIds so we can correlate logs properly.

yeah, probably need to remove the lazyTraceId then as there isn't a benefit if we're immediately going to generate the String form for MDC.

It may still be helpful for span IDs, which iirc use the same function. If we have 500 spans per trace, that may provide a sizable improvement.

iamdanfox · 2019-06-07T12:24:17Z

 */
 public final class Trace {

+ private static final Trace NOOP = new Trace(false, "noop");


Could we put a one-liner of javadoc on this guy to say that we just re-use this single instance for all non-observable traces?

carterkozak · 2019-06-14T19:27:37Z

I think we still need to track span depth for non-sampled traces. When the root span is completed via Tracer.completeSpan/fastCompleteSpan the trace thread state is removed, along with the traceId MDC value. An approach I've considered is to use a different data type for sampled and unsampled traces, where unsampled traces have a traceId and a counter in place of the stack of spans. when the counter is decremented to zero, we can remove thread state.

schlosna · 2019-06-20T19:23:56Z

closing in favor of #180

schlosna · 2019-06-06T21:39:31Z

Before this PR

Related to #167 there is a lot of memory allocation, garbage collection overhead, and CPU overhead of random ID generation for trace IDs and spans when traces are not observable (i.e. either not explicitly defined as observable or not selected for sampling).

After this PR

Avoid creating spans when the containing trace is not observable and lazily generate trace IDs only for observable traces to avoid the memory allocation, garbage collection overhead, and CPU overhead of random generation.

Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

iamdanfox · 2019-06-07T12:17:26Z

+ return NOOP;
+ }
+
 Trace(boolean isObservable, String traceId) {


Wanna mark this @VisibleForTesting and make DeferredTracer call your new static create method?

carterkozak · 2019-06-07T12:21:09Z

+ return new Trace(isObservable, traceId.toString());
+ }
+ return NOOP;
+ }


I think we still need to generate random trace IDs for non-observable traces, since the ID is applied to requests and logging MDC allowing us to load all the logs for an operation across services, even when the operation has not been sampled.
Fortunately traces are relatively uncommon, spans are created significantly more frequently, and the span ids are unimportant for unsampled traces.

Mmm good point, setTrace will always call MDC.put(Tracers.TRACE_ID_KEY, trace.getTraceId());, and we really do want those traceIds so we can correlate logs properly.

yeah, probably need to remove the lazyTraceId then as there isn't a benefit if we're immediately going to generate the String form for MDC.

It may still be helpful for span IDs, which iirc use the same function. If we have 500 spans per trace, that may provide a sizable improvement.

iamdanfox · 2019-06-07T12:24:17Z

 */
 public final class Trace {

+ private static final Trace NOOP = new Trace(false, "noop");


Could we put a one-liner of javadoc on this guy to say that we just re-use this single instance for all non-observable traces?

carterkozak · 2019-06-14T19:27:37Z

I think we still need to track span depth for non-sampled traces. When the root span is completed via Tracer.completeSpan/fastCompleteSpan the trace thread state is removed, along with the traceId MDC value. An approach I've considered is to use a different data type for sampled and unsampled traces, where unsampled traces have a traceId and a counter in place of the stack of spans. when the counter is decremented to zero, we can remove thread state.

schlosna · 2019-06-20T19:23:56Z

closing in favor of #180

schlosna added 2 commits June 6, 2019 17:28

Avoid trace ID allocations when not observing
e83d76e
Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

Avoid creating spans when trace is not observable
96651be

schlosna requested a review from a team as a code owner June 6, 2019 21:39

update tests to handle optionals properly
d8c16ab

schlosna mentioned this pull request Jun 7, 2019
Add JMH benchmarks #169
Closed

iamdanfox reviewed Jun 7, 2019
View reviewed changes

carterkozak reviewed Jun 7, 2019
View reviewed changes

iamdanfox reviewed Jun 7, 2019
View reviewed changes

Remove lazy trace ID generation
de0800f

wenhoujx mentioned this pull request Jun 14, 2019
[improvement] add jmh to tracing-java #175
Closed

schlosna mentioned this pull request Jun 14, 2019
[improvement] Add JMH benchmark project #176
Closed

schlosna closed this Jun 20, 2019

schlosna deleted the ds/lazy-trace-id branch June 20, 2019 19:24

schlosna added 2 commits June 6, 2019 17:28

Avoid trace ID allocations when not observing
e83d76e
Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

Avoid creating spans when trace is not observable
96651be

schlosna requested a review from a team as a code owner June 6, 2019 21:39

update tests to handle optionals properly
d8c16ab

schlosna mentioned this pull request Jun 7, 2019
Add JMH benchmarks #169
Closed

iamdanfox reviewed Jun 7, 2019
View reviewed changes

carterkozak reviewed Jun 7, 2019
View reviewed changes

iamdanfox reviewed Jun 7, 2019
View reviewed changes

Remove lazy trace ID generation
de0800f

wenhoujx mentioned this pull request Jun 14, 2019
[improvement] add jmh to tracing-java #175
Closed

schlosna mentioned this pull request Jun 14, 2019
[improvement] Add JMH benchmark project #176
Closed

schlosna closed this Jun 20, 2019

schlosna deleted the ds/lazy-trace-id branch June 20, 2019 19:24

schlosna added 2 commits June 6, 2019 17:28

Avoid trace ID allocations when not observing
e83d76e
Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

Avoid creating spans when trace is not observable
96651be

schlosna requested a review from a team as a code owner June 6, 2019 21:39

update tests to handle optionals properly
d8c16ab

schlosna mentioned this pull request Jun 7, 2019
Add JMH benchmarks #169
Closed

iamdanfox reviewed Jun 7, 2019
View reviewed changes

carterkozak reviewed Jun 7, 2019
View reviewed changes

iamdanfox reviewed Jun 7, 2019
View reviewed changes

Remove lazy trace ID generation
de0800f

wenhoujx mentioned this pull request Jun 14, 2019
[improvement] add jmh to tracing-java #175
Closed

schlosna mentioned this pull request Jun 14, 2019
[improvement] Add JMH benchmark project #176
Closed

schlosna closed this Jun 20, 2019

schlosna deleted the ds/lazy-trace-id branch June 20, 2019 19:24

schlosna added 2 commits June 6, 2019 17:28

Avoid trace ID allocations when not observing
e83d76e
Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

Avoid creating spans when trace is not observable
96651be

schlosna requested a review from a team as a code owner June 6, 2019 21:39

update tests to handle optionals properly
d8c16ab

schlosna mentioned this pull request Jun 7, 2019
Add JMH benchmarks #169
Closed

iamdanfox reviewed Jun 7, 2019
View reviewed changes

carterkozak reviewed Jun 7, 2019
View reviewed changes

iamdanfox reviewed Jun 7, 2019
View reviewed changes

Remove lazy trace ID generation
de0800f

wenhoujx mentioned this pull request Jun 14, 2019
[improvement] add jmh to tracing-java #175
Closed

schlosna mentioned this pull request Jun 14, 2019
[improvement] Add JMH benchmark project #176
Closed

schlosna closed this Jun 20, 2019

schlosna deleted the ds/lazy-trace-id branch June 20, 2019 19:24

schlosna added 2 commits June 6, 2019 17:28

Avoid trace ID allocations when not observing
e83d76e
Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

Avoid creating spans when trace is not observable
96651be

schlosna requested a review from a team as a code owner June 6, 2019 21:39

update tests to handle optionals properly
d8c16ab

schlosna mentioned this pull request Jun 7, 2019
Add JMH benchmarks #169
Closed

iamdanfox reviewed Jun 7, 2019
View reviewed changes

carterkozak reviewed Jun 7, 2019
View reviewed changes

iamdanfox reviewed Jun 7, 2019
View reviewed changes

Remove lazy trace ID generation
de0800f

wenhoujx mentioned this pull request Jun 14, 2019
[improvement] add jmh to tracing-java #175
Closed

schlosna mentioned this pull request Jun 14, 2019
[improvement] Add JMH benchmark project #176
Closed

schlosna closed this Jun 20, 2019

schlosna deleted the ds/lazy-trace-id branch June 20, 2019 19:24

schlosna added 2 commits June 6, 2019 17:28

Avoid trace ID allocations when not observing
e83d76e
Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

Avoid creating spans when trace is not observable
96651be

schlosna requested a review from a team as a code owner June 6, 2019 21:39

update tests to handle optionals properly
d8c16ab

schlosna mentioned this pull request Jun 7, 2019
Add JMH benchmarks #169
Closed

iamdanfox reviewed Jun 7, 2019
View reviewed changes

carterkozak reviewed Jun 7, 2019
View reviewed changes

iamdanfox reviewed Jun 7, 2019
View reviewed changes

Remove lazy trace ID generation
de0800f

wenhoujx mentioned this pull request Jun 14, 2019
[improvement] add jmh to tracing-java #175
Closed

schlosna mentioned this pull request Jun 14, 2019
[improvement] Add JMH benchmark project #176
Closed

schlosna closed this Jun 20, 2019

schlosna deleted the ds/lazy-trace-id branch June 20, 2019 19:24

schlosna added 2 commits June 6, 2019 17:28

Avoid trace ID allocations when not observing
e83d76e
Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

Avoid creating spans when trace is not observable
96651be

schlosna requested a review from a team as a code owner June 6, 2019 21:39

update tests to handle optionals properly
d8c16ab

schlosna mentioned this pull request Jun 7, 2019
Add JMH benchmarks #169
Closed

iamdanfox reviewed Jun 7, 2019
View reviewed changes

carterkozak reviewed Jun 7, 2019
View reviewed changes

iamdanfox reviewed Jun 7, 2019
View reviewed changes

Remove lazy trace ID generation
de0800f

wenhoujx mentioned this pull request Jun 14, 2019
[improvement] add jmh to tracing-java #175
Closed

schlosna mentioned this pull request Jun 14, 2019
[improvement] Add JMH benchmark project #176
Closed

schlosna closed this Jun 20, 2019

schlosna deleted the ds/lazy-trace-id branch June 20, 2019 19:24

schlosna added 2 commits June 6, 2019 17:28

Avoid trace ID allocations when not observing
e83d76e
Lazily generate trace IDs only for observable traces to avoid the memory allocation, GC, and CPU overhead of random generation.

Avoid creating spans when trace is not observable
96651be

schlosna requested a review from a team as a code owner June 6, 2019 21:39

update tests to handle optionals properly
d8c16ab

schlosna mentioned this pull request Jun 7, 2019
Add JMH benchmarks #169
Closed

iamdanfox reviewed Jun 7, 2019
View reviewed changes

carterkozak reviewed Jun 7, 2019
View reviewed changes

iamdanfox reviewed Jun 7, 2019
View reviewed changes

Remove lazy trace ID generation
de0800f

wenhoujx mentioned this pull request Jun 14, 2019
[improvement] add jmh to tracing-java #175
Closed

schlosna mentioned this pull request Jun 14, 2019
[improvement] Add JMH benchmark project #176
Closed

schlosna closed this Jun 20, 2019

schlosna deleted the ds/lazy-trace-id branch June 20, 2019 19:24

Uh oh!

Conversation

schlosna commented Jun 6, 2019

Before this PR

After this PR

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carterkozak commented Jun 14, 2019

Uh oh!

schlosna commented Jun 20, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

schlosna commented Jun 6, 2019

Before this PR

After this PR

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carterkozak commented Jun 14, 2019

Uh oh!

schlosna commented Jun 20, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

schlosna commented Jun 6, 2019

Before this PR

After this PR

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carterkozak commented Jun 14, 2019

Uh oh!