Performance API

[philipphofmann]

Discussion about the performance API here #909

[philipphofmann]

I would propose a few changes then to the whole API. For simplicity, I skipped Sentry in the naming.

1. Span shouldn't inherit from SpanContext, but instead, have a property to it.
2. Add protocols for Span and Transaction with NoOps
3. Rename the classes Span and Transaction to something like InternalSpan and InternalTransaction
4. Extract a base class BaseEvent from Event and let both Transaction and Event inherit from it.

This would look something like this.

[philipphofmann]

That makes sense, but do you think it's worth the effort of adding an interface and a NoOP implementation just for the case when the SDK is disabled? Yes, a NoOp saves the user a lot of extra work, but we can discard the transactions when calling the hub. What do you think @bruno-garcia and @brustolin ?

[marandaneto]

@philipphofmann that's what .NET did, the downside is, allocation, we are allocating objects that are not gonna be used, it'd be cheaper to have a NoOp that does nothing.

[philipphofmann]

I think a more straightforward API is more important than optimizing for when the SDK is disabled. I think it's okay that the SDK still allocates a few objects in that case. The most important thing is that the actual transaction is fast IMO.

[bruno-garcia]

That can be used to link errors at least (even though transaciton was unsampled)

that's the point, if the transaction is unsampled, you link errors but transactions wont be sent anyway, so what's the benefit I am missing?

Benefit is linked errors front-end and back-end

[bruno-garcia]

@philipphofmann that's what .NET did, the downside is, allocation, we are allocating objects that are not gonna be used, it'd be cheaper to have a NoOp that does nothing.

Saving on allocations isn't the only reason to use a NoOp, it's also the "null pattern" which was also nice when languages didn't have null annotations and users could end up with NPE if they weren't careful.
I often point out to saved allocation when I spot one but doesn't mean we need to drive the design solely by that mindset, I honestly am thorn about NoOp transactions because of the limitation of not propagating the trace-id and limiting the ability to link errors in different services. The allocation of a single object is trivial, specially compared with the value we get from linking errors.

I'm OK with keeping our options open here and always return a transaction instance, with sampled=false but an id. Optimization could exist in avoid creating Spans when the transactions is unsampled? There I see no value in allocating since the spans won't be captured. But a trace-id and propagation we should aim getting to work.

[philipphofmann]

According to @mitsuhiko, we should try to keep transactions private and only expose spans if possible.

[philipphofmann]

Why is the description for startChild nullable when we have an overload without the description? Can we make it non-nullable?

span.startChild(operation: "Child 1 Child", description: nil)
transaction.startChild(operation: "Child 2", description: nil)

[philipphofmann]

Is addressed in #1059

[armcknight]

This has been stale for a while so closing it as outdated.