sentry-rust

sentry-rust copied to clipboard

Span management operations seem to be relatively costly, making them unsuited for profiling otherwise fast ~zero-alloc code.

This wouldn't matter much if it was only for sampled transactions, but this is actually for every one of them: Notably after fetching the current scope: https://github.com/getsentry/sentry-rust/blob/e828ca28a53994a64ef91e72f1f6fe7e10c6ea3c/sentry-tracing/src/layer.rs#L210

There's no way to check whether it will eventually be sampled.

This means that integrations such as that of tracing but also custom integrations (I'm writing one at the moment) can't avoid generating a bunch of Strings, Arcs, serde_json::Value for every Span that the framework may decide to sample, even though the framework already knows that it won't be sampled, e.g.: https://github.com/getsentry/sentry-rust/blob/e828ca28a53994a64ef91e72f1f6fe7e10c6ea3c/sentry-tracing/src/layer.rs#L218-L222 (Where in most integrations, one could avoid generating a Value, if the trace won't be sampled.)

It looks like one could benefit of being able to:

• Identify from a TransactionOrSpan whether it will be sampled, allowing to not create sub-spans and all their resources unless necessary
• When creating new transactions, getting access to the sampling API so that we can know in advance whether the transaction will be sampled, and if not, not allocate e.g. Strings to build description, that then even get re-allocated in TransactionContext.