Using the Observation beta in computationally expensive use cases

[raghavbhasin97]

Hey all, so I have ben playing around with the branch and migrated away a key piece of my app which does some really computationally expensive stuff.
I have a couple 1000 data points and use those to calculate data for a chart. This has to be done on the fly since the parameters for calculation are highly customizable.
I used a ViewState pattern initially and it worked fine. With the observation stuff I simply converted over the things from ViewStore to store and changed the callsites to be store.view (where view is the computed view state). I have to structure it this way with view because different components of ViewState reuse some base computations so destructing would only make it more computationally expensive.
I have the View wrapped in WithPerceptionTracking
I am seeing that this setup takes a huge hit on the performance. Specially with having an interactive gesture on the chart that is sending actions to the reducer on user dragging over it. (I do have sorts of a cache in there to prevent the recompilation of the whole thing when user is interacting) But it still seems to take a hit.
Any suggestions on how to get back the original ViewStore performance?

[mbrandonw]

Hi @raghavbhasin97, a few things come to mind:

1. Are you using the most recent commit from observation-beta? There were some changes merged recently to improve a DEBUG-only check inside WithPerceptionView. If you don't have that commit, then I would hope updating to the newest would help a lot.
2. If you are already on the most recent commit, or if those performance improvements didn't help, then can you try running your app in release? That causes the DEBUG-only check to go away. Does performance go back to normal? If so, then that may mean there are further optimizations that could be done inside WithPerceptionTracking.
3. Are you literally doing store.view.someField multiple times throughout your view? If so, that means a fresh copy of store.view will be re-computed every time. You can just compute it a single time at the top of the view:

   var body: some View {
     let viewState = store.view
     // Use viewState everywhere
   }

4. And finally, if none of the above works, can you run your app in the profiler instrument to see if anything stands out?

[raghavbhasin97]

@mbrandonw
Thanks, I can confirm that it was the recomputation of store.view not sure what I was thinking there. I went from an @ObservedObject var viewStore: with a bunch of smaller Views inside to the new way just replaced the stuff inlace.
having the viewState computed on top definitely returns back the performance. I will keep this mind for future.
Thanks again for talking a quick look.

[mbrandonw]

Great to hear, glad it was something simple :)