I just noticed the initialization of EditorResources.styleCatalog costs between 1.4 and 2s of my <5s assembly reload times. Tested on the latest alpha 2020.1.0a9.
It seems most of the cost comes from string operations.
I just noticed the initialization of EditorResources.styleCatalog costs between 1.4 and 2s of my <5s assembly reload times. Tested on the latest alpha 2020.1.0a9.
It seems most of the cost comes from string operations.
Hi, do you have any custom uss files in your project that could explain these load times? If you do, can you share them with me and I’ll make sure this gets optimized.
Thanks,
I don’t has any custom uss around, and I see similar (but lower) times on empty projects. I have 2D Sprite, QuickSearch and TextMesh Pro packages.
The cost seems to come all from string operations and heavy usage of IndexOf on lists. For the IndexOf hit, maybe it should use a better structure during data generation, so it won’t call IndexOf so many times. Then use ToList or similar when done, if an actual List is required.
If I have the time later, I’ll read the code and see if I can understand what is happening a bit better.
Thanks for the reply.
I have an upcoming performance fix for this issue. I’ll let you know when it will be available for testing in the Hub.
The optimization is not in yet. Here’s a preview of the numbers you should get:
High level performance tracker:
Deep Profile trace:
Compared to this (without the optimization):
So now ExpandValues should scale much better with the increasing number of extended styles and it should take much less memory too.
Oh wow, those look great!
Is that Performance tracker available somewhere? Seems pretty useful.
The package is still internal, but if should be usable (latest 2020.1 only).
You can drop the package as an embedded package. Then the window will be available through:
Then you should see all the available perf trackers:
Unfortunately, the API to add new performance trackers is still internal, but if you have access to internal API you can do something like this to add new ones:
using (new EditorPerformanceTracker("Tracker.PerformNotifications"))
{
PerformNotifications(now, trackerNames);
}
Full API looks like this:
internal struct EditorPerformanceTracker
{
public static extern string[] GetAvailableTrackers();
public static extern bool Exists(string trackerName);
public static extern void Reset(string trackerName);
public static extern int GetSampleCount(string trackerName);
public static extern double GetLastTime(string trackerName);
public static extern double GetPeakTime(string trackerName);
public static extern double GetAverageTime(string trackerName);
public static extern double GetTotalTime(string trackerName);
public static extern double GetTotalUsage(string trackerName);
public static extern double GetTimestamp(string trackerName);
public static extern void LogCallstack(string trackerName);
public static extern void GetCallstack(string trackerName, Action<string> onCallstackCaptured);
internal static extern int StartTracker(string trackerName);
internal static extern void StopTracker(int trackerToken);
}
Awesome.
It’s working nicely (only had to deleted te Tests because some were broken).
This is a very useful package. Thank you!
Just saw the changelog for a15.
Did a quick test today and StyleCatalog.Load is down from ~1.4s to ~0.83
Still taking quite a bit of time, but better than before!
I also noticed some new UIElements things, taking quite a bit of time now.
Examples: Toolbar.OnEnable (taking almost 600ms).
Any idea if this is being tracked? Should I submit a report?
Wait for the next release, now the style catalog is being serialized and reloaded from disk for all subsequent domain reload, so when entering play mode, reloading the style catalog shouldn’t take more than 30-50 ms.
Oh, that’s some awesome news!
I’ll keep an eye out for it. I’ll wait until the next alpha to see if the Toolbar.OnEnable hit is still there too.
Thanks for keeping us posted!
I completely forgot about this thread, so the performance improvements should have worked. Thanks!
Incidentally, did the performance tracking package ever get released or is it still internal only? It’s a great tool!
I remembered this thread because I was reading the editor.log today after a crash and noticed lots of detailed [Performance] information. Pretty cool.
We will release it on https://github.com/unity-technologies in the upcoming weeks.
Thanks for the feedback
The package is now publicly available here https://github.com/Unity-Technologies/com.unity.performance-tracking
Do not hesitate to give us feedback.