span-reporter span id generation is very slow.

[rohitprg]

https://github.com/opentracing-contrib/java-span-reporter/blob/6e65e7fc88ebc9efdd0fc5522a391bbc01be8e4f/span-reporter/src/main/java/io/opentracing/contrib/reporter/SpanBuilderR.java#L113

Span reporter uses UUID.randomUUID() to generate the span id, which internally uses SecureRandom and is very slow.

Whereas tracer server like Jaeger uses Java6CompatibleThreadLocalRandom.current().nextLong() which is 10 times faster with no contention(one thread) and around 50 to 100 times faster with contention (multilple threads) compared to UUID.randomUUID().

Instead of creating its own span id, span reporter can get the span id from the tracing implementation i.e. wspan.context().toSpanId(). Could span-reporter use random instead of uuid or something like below??

@Override
public Span start() {
    Span wspan = wrapped.start();
    String spanId;
    SpanContext spanContext = wspan.context();
    if (spanContext != null) {
        spanId = spanContext.toSpanId();
    } else {
        spanId = UUID.randomUUID().toString();
        wspan.setBaggageItem(BAGGAGE_SPANID_KEY, spanId);
    }

This is a picture profiled on my production server. The cost comes from the following areas:

SpanBuilderR.start():
    UUID.randomUUID(): 17%
    Adding the custom id to baggageItems: 13%
    UUID.toString(): 2%
SpanBuilderR.addReference: when we set a span as a child of another span we need to search the baggage items for the custom span id: 2%

Providing an option to use the tracing implementations span id will completely remove this cost.