Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Component render details #173

Open
sregg opened this issue Sep 20, 2022 · 5 comments
Open

[FEATURE] Component render details #173

sregg opened this issue Sep 20, 2022 · 5 comments

Comments

@sregg
Copy link

sregg commented Sep 20, 2022

Describe the solution you'd like
We started using reassure to measure a particular screen's performance. To be able to render it in the right conditions, we currently render our entire app navigation container with all the necessary context providers (e.g. Jotai, RQ, NativeBase, etc...) and navigate to that problematic screen (i.e. open a modal screen).
We running that test, we see that it takes on average 500ms and 20 re-renders.
It'd be great to have a way to see what components took the longest and re-rendered the most during that test. Maybe we can specify a list of component names to track (e.g. high level screen components) or track the slowest 10 or only n level deep.

Describe alternatives you've considered
We're currently using the Profiler inside ReactDevTools (inside Flipper) to see those component render times. It's pretty good for debugging but it'd be great if we can have them from our automated perf tests as well.

Additional context
I'd be happy to contribute if you think this is a feasible feature to implement.

Thanks for this amazing tool. Render (and re-render) issues are the bottleneck of our app right now (we think NativeBase is not helping here). We're working hard on fixing some of these issues but we need a way to prevent future regressions. It's reassuring (pun intended) to see there's a tool that can warn us now.

@thymikee
Copy link
Member

Hey @sregg! Thanks for using Reassure. I think I'm not opposed to add such a feature, ideally behind a flag. We already collect details about subsequent render durations in the whole test runs, so there's a precedence to add more detailed data.

Any thoughts @mdjastrzebski @Xiltyn?

@mdjastrzebski
Copy link
Member

In general Reassure's goal is to measure performance of the whole test scenarios, as other tools (mainly Dev Tools Profiler in Flipper) are better suited for diagnosing the details for render performance.

That being said, some additional performance hints by Reassure could be useful if implemented in a way that does complicate the primary use case.

From technical pov Reassure wraps whole passed JSX element tree with React.Profiler. It seems that the only way to measure the member components is to wrap each of them in their own React.Profiler HOC. That could be done either by user, by adding <React.Profiler> instances to the element tree, or by Reassure by somehow analysing and modifying the received element tree, based on e.g. names of the components to measure.

@sregg feel free to explore the idea, targeted use cases, potential API, etc.

Couple of random thoughts that might be useful:

  • React.Profiler measure the render duration of whole component tree wrapped by it, not only the most outer component.
  • In case of lists, you have a number of similar components where each one has its own render duration while all share the same.

@thymikee
Copy link
Member

I believe we could also leverage onRender from React.Profiler? https://reactjs.org/docs/profiler.html#onrender-callback

@mdjastrzebski
Copy link
Member

We already use onRender from React.Profiler to receive profiler stats, but that does not give use any insights in the child components. Afaik you would need to wrap each relevant descendant component in its own React.Profiler to achieve that.

@Xiltyn
Copy link
Collaborator

Xiltyn commented Feb 7, 2023

To comment on the above. Just like @mdjastrzebski have said - it is possible to achieve this result only by wrapping children in React.Profiler HOC as well. That way you could manipulate the data accordingly to produce comparisons between components and such. In fact, we worked with that kind of a setup in the past, but Reassure by itself doesn't support or provide a mechanism for automatic wrapping of components across the repository or its parts. A babel plugin would be the easiest way to achieve the effect, but at the same time it is far from easy :)

At that point I would also be worried about potential impact of all those React.Profilers on performance in general.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants