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
- Missing space in Cache Server documentation link tooltip in Project Settings
- Android soft keyboard's arrows and select tools do not have visual feedback when Hide Mobile Input is enabled
- No padding in the UI Toolkit Project Settings
- Unity Perforce: Connection is extremely slow or times out when "Scan Local Packages on Connect" is enabled in Version Control while the project has many local packages
- Not compatible Style Sheets can be selected in the TSS files under "Style Sheets"
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.