feat(profiling): remove profiling support

[viglia]

The profiler produced questionable sample rates, we frequently saw gaps that were multiple seconds long. This meant that we couldnt not have strong confidence in the quality of the data

[codecov]

Codecov Report

Merging #595 (867f9af) into master (3ab112c) will increase coverage by 2.50%.
The diff coverage is 100.00%.

❗ Current head 867f9af differs from pull request most recent head 3e6e0da. Consider uploading reports for the commit 3e6e0da to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #595      +/-   ##
==========================================
+ Coverage   70.80%   73.30%   +2.50%     
==========================================
  Files          67       65       -2     
  Lines        6857     6579     -278     
==========================================
- Hits         4855     4823      -32     
+ Misses       2002     1756     -246     

[Swatinem]

sad to see it go. we were quite close turning this on in S4S :-D

[penso]

Would love to see some profiling back to Sentry/Rust.

[outductor]

Any chance profiling comes back in the future roadmap?

[Swatinem]

The problem we had with this implementation was that the sampling accuracy was very low, which means we did not have samples takes at predictable intervals, of predictable threads.

Coupled with the fact that this whole product feature was tied to the performance monitoring product, which has rather short-lived transactions of a single execution flow.
That, together with the fact that we have multithreaded work-stealing executors for async Rust means that this was a bad fit.
The performance-monitoring part, which is powered primarily by #[tracing::instrument] and thus very accurate, does not really work well with sampling profiling if you consider that the code you are instrumenting is most likely async which can yield to other threads and also change threads.
It is thus very hard to relate the samples collected in profiling to the actual transaction / span you want to profile.

Long story short, we decided to rather remove this integration from the SDK, rather than have a suboptimal experience.

I totally understand the interest in this feature though, and I will make sure to forward this feedback internally.