Measuring runtime performance

[AttwellBrian]

If I add .to(new ObservableScoper<RequestLocation>(lifecycle)) to an observable it makes it noticeably slower. Not super slow: just 0.13ms on a pixel (I put this in a loop with 500 iterations and measured the increase in duration). But slower than using a simple composite disposable pattern.

Some thoughts from a chat with Zac below

The exec path under the hood when you do this (this point when you call to()):

• create new Scoper
• scoper implements subscribeproxy

(this point on happens when you call subscribe())

• calling subscribe creates an autodisposing observable, which is just a normal observable that has a custom observer in subscribeActual
• the custom observer implements AutoDisposingObserver, creates an extra subscription on the lifecycle
• all pub sub from there

potential areas of wins:

• don't use consumers for lifecycle subscription to avoid unnecessary rxjava LambdaObserver creation
• Maybe LifecycleScopeProvider could be lazier, but I doubt it. It already defer()'s to subscribe()-time, but if you want boundary checks there then you have to do it synchronously

[ZacSweers]

Do you have more concrete numbers on those different parts? It is going to be slower than not using autodispose for obvious reasons, but it’s hard to see where any issue is without more details

[AttwellBrian]

When tried it in the Rider app, it appeared to take 0.5% of main thread time. I only measured two iterations of the following test: app start + trip start.

Wasn't big enough of an issue to dig into more. But did want to write this up in case there was any obvious wins you could think of.

[ZacSweers]

Going to close this as inactionable for now, happy to revisit if anyone sees anything concerning!