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

[Performance] Window OnEnable() is slow #57

Open
unitystevem opened this issue Jul 14, 2021 · 3 comments
Open

[Performance] Window OnEnable() is slow #57

unitystevem opened this issue Jul 14, 2021 · 3 comments
Assignees

Comments

@unitystevem
Copy link
Contributor

My most recent Project Review, which focused heavily on Editor performance and iteration times, showed that the Project Auditor window's OnEnable() method is relatively expensive. Definitely not the worst offender, but it would be good to improve this if possible. This is what it looks like with the PA window open when you make a small code change and the assembly reload process refreshes all of the open windows in the Editor. Taken from Profile Analyzer, and filtered by OnEnable() . This impacts assembly recompilation/reload after every code change, and entering/exiting Play Mode if domain reload is not disabled.

OnEnableCosts

@mtrive
Copy link
Contributor

mtrive commented Jul 22, 2021

Since this is a real world project, ~139ms does not look to bad to me, no?
Reloading assemblies usually take much longer, in the order of seconds so, to be honest, I am not sure it's worth optimizing the ProjectAuditorWindow.OnEnable.
If you agree, I'd rather improve the time it takes to analyze a project.

@unitystevem
Copy link
Contributor Author

I agree that it's not an enormous problem, although that cost does impact every single iteration event in Unity, and (aside from the Settings Window, which is pretty terrible), Project Auditor is the most expensive window to refresh that I've seen.

I agree that focusing on project analysis time should be higher priority. Are you suggesting that we put this issue at the bottom of the priority list, or that it should just be closed as "by design"?

@mtrive mtrive self-assigned this Jul 29, 2021
@mtrive
Copy link
Contributor

mtrive commented Jul 29, 2021

I would not close as "by design". I would definitely like to profile the OnEnable as well as the de/serialization of the report data on a large project since they can both impact iteration times and they are tightly coupled.

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

2 participants