Search Issue Tracker
Won't Fix
Votes
1
Found in
2019.3.0a1
2019.4
2019.4.4f1
2020.1
2020.2
Issue ID
1269456
Regression
Yes
Asset renaming is slow until library folder is deleted
How to reproduce:
1. Open the attached project. Check an edit below for more information
2. Select the Canvas object in the Project window
3. Re-name the object
Expected result: Editor rapidly changes the name of the asset without a noticeable slowdown
Actual result: A noticeable slowdown is experienced
Reproducible with: 2019.3.0a1, 2019.4.8f1, 2020.1.3f1, 2020.2.0a21 (asset import pipeline version 2)
Not reproducible with: 2018.4.26f1, 2019.3.0a1 (asset import pipeline version 1)
Other examples when the issue is visible:
1) When editing a prefab selecting it in the project view. You edit a field and then the import process kicks in.
2) When cloning things In the project, like for example a material
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Shader Compilation for projects with lots of Shaders can be slow (i.e. VFX Graph asset heavy projects)
- Crash on RebuildTransformHierarchyOrMarkForDestruction when opening a scene
- The Editor hangs when opening a project that uses local packages and Version Control
- Area Light is culled when Camera Frustrum is outside the lights range
- The characters of the bottom option in the Scene View Debug Draw Mode dropdown menu are cut off
Resolution Note (2020.2.X):
The performance doesn't depend on the library folder.
It depends on how many objects are there in memory at the time of renaming the asset (which has a Refresh operation).
I.e. whether the sample scene in this project was loaded or not. (in 19.4 this means ~260000 objects in memory)
V2 makes sure that the list assets loaded before and after a Refresh stays consistent and the objects are up to date.
Part of this process requires to take a snapshot of the list of loaded objects so we can restore that later.
This was required to fix number of bugs we had in V1, but it doesn't come for free.
Nevertheless we believe that the performance in 19.4 can be improved and in fact we have been working on improving it.
V2 is still in active development and a lot has changed in the code since 19.4.
In 19.4 the operation took 1200 ms, in 20.2 it's only 300 ms and we plan to improve this further in the future.
Unfortunately these improvements can't be safely backported to 19.4 as there are simply too many changes.