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
- Any small change in UI Builder Inspector refreshes Editor Inspector
- Inaccurate Box Collider boundaries on a rotated child Cube when the parent GameObject Scale is non-uniform
- [Android] "SHADOWS_SCREEN" set as shader Keyword when no "_ShadowMapTexture" is bound leads to freeze on a build on some Mali GPU devices
- The global scene list is overridden in a project built with command line when the Override Global Scene List setting is disabled in the build profile
- Global Scenes are not included in the Build when building multiple Build Profiles at the same time
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.