With the new prefab improvements saving prefabs has become a huge issue for me. It takes over 20 seconds to save a prefab that has about 250 gameobjects in it and is used a handful of times in several scenes. This obviously makes Auto-Save not remotely viable and even just occasional saving has slowed down my workflow a lot compared to pre-2018.3.
Is the performance still a work in progress? Are there things I can do to improve it?
Prefab saving in itself should not have gotten significantly slower for an object of that size. There might be slight decrease because Prefab now have to be imported whenever they are saved, but it should not approach anything near 20 seconds for 250 GameObjects.
What might be happening is that a lot of other things are dependent on the Prefab you’re saving. If the Prefab is used as a nested Prefab in many other Prefabs, or is the base of many Prefab Variants, then all of those Prefabs that are dependent on this one need to be re-imported as well. Obviously such a setup was not possible previously, since there was no nested Prefabs or Prefab Variants.
If you see a performance decrease even for a Prefab with nothing that depends on it, then that’s a real issue and we would appreciate a bug report about it. Particularly if you can show it with a Prefab from 2018.2 or earlier and compare the time for saving it there with how long it takes in 2018.3.
Apart from that we’re focused on performance in general and future improvements to Unity’s Asset Database (which is actively in development as we speak) and handling of dependencies should eventually have a positive effect for Prefabs as well, but currently we’re a bit constrained by the existing technology stack in Unity.
Thanks for the response–I’ll see if I can test it in 2018.2 vs 2018.3.
Hi. I also noticed longer saving time since 2018.3. Found the origin of the problem in my case, wanted to share it here.
Some prefabs had a script with OnValidate method. OnValidate is called when saving the scene. It could slow down the saving.
In my case, the problematic line was setting the light (realtime) intensity (or light color depending on cases). Even if the set value was the same as the current value. Just added an if case to compare current and new value, and set only if necessary. I guess it was forcing recalculating the light. Don’t know if it should be considered as a bug or not.
Will try to reproduce the problem in an empty project and send a bug report, in case of.
I also noticed an immediate increase in the time to save a scene in my project after upgrading to 2018.3. Even saving a blank empty unchanged scene took 3 seconds, with the cursor flashing between arrow and progress circle. Larger scenes were taking 5-6 seconds. All saving had been < 1 second before.
Restarting Unity fixed the problem.
I’d been working with several prefabs referenced ~50 times in one scene, including a nested one. I’m guessing Unity had them flagged as changed and was checking them over and over on every save? I haven’t seen the issue since. In case other people have this issue, try restarting before you waste time debugging it.
This is problematic, but an increase in time in saving an empty scene without Prefabs is unlikely to be related to Prefabs. There are plenty of other changes in 2018.3.
If you have larger scenes that do contain Prefabs and want to check how much of the time it takes to save them might be related to Prefab functionality, you could make a copy of the scene where you unpack all Prefabs completely, so there’s the same amount of objects but no longer any Prefabs, and then save that for comparison.
If you have a reliable slowdown between 100% comparable scenes in 2018.3 versus 2018.2, feel free to file a bug report (please attach the project prior to 2018.3 upgrade so we can open it in 2018.2 too) so our QA can have a look at it and send it to a relevant team as appropriate.
Hi, I got exactly the same issue. Reliable slowdown between 2018.3 and 2018.2 - compared scenes with prefabs (no variants, no nesting) and the same scene with “unpack all Prefabs completely”.
Submitted a bug report with the completed project as I was unable to isolate it in a smaller project. Case 1122675
There was a performance regression in saving very large prefabs, this has been fixed and next patch should be better.
Unless of course this is something completely different 
Update to Unity 2018.3.4f1 didn’t help
Could you please send in a bug report so I can have a look at it.
It is already submitted, as I wrote earlier. Case 1122675
Oh sorry missed that
Update to Unity 2018.3.5f1 didn’t help
Update to Unity 2018.3.6f1 didn’t help - still very unusable. Any progress on that? I am thinking fo switching back to 2018.2
We’re running Unity 2018.3.0f2 and are experiencing a similar problem - saving the project (not the scene) is quite slow ever since we upgraded to 2018.3. I believe this is due to prefabs.
Here’s how much time it took on an M.2 SSD for (what it looks like to be) 38 prefabs to save. Obviously, you should take this with a grain of salt since this is a Deep Profile, but I can assure you that it feels just as slow without the Profiler active.
This issue is compounded by the fact that we change prefabs on runtime (a tiny change that calls SetActive on them) which causes a huge number of prefabs to become Dirty and have to resaved. Accidentally hitting Ctrl+S (you know… it’s a habit that’s hard to get out of) seems to be a shortcut for taking a coffee break, since Unity will be locked up for the next minute or two.
Potentially this might be an issue only with our project since it’s relatively big, but I’ve noticed the Prefab save progress dialogue pop up even on a smaller project (though it takes much shorter), whereas before 2018.3 I never noticed such a slowdown when saving a small project
Yes I have closed a few bugs as won't fix exactly because of this. If someone changes the prefabs we have to save them when saving the project, this is no different than before. You are seeing a performance impact because now prefabs are also imported.
My recommendation is to not touch the prefab assets unless you absolutely have to, in your case I doubt you have to touch it, but I am curious as to why you are touching them?
finally got to your project and you have exactly the issue described above. Something touches the prefab assets after the first time the scene is saved. I don’t know what is touching the prefabs.
We’re also experiencing this issue in 2018.3.6f1.
We’re doing a good amount of OnValidate throughout our scripts. Saving a scene or duplicating something in the project panel lags the editor for about 20 seconds.
Edit: Saving a scene with “Save as” saves instantaneously but I assume that’s because “Save” is saving the scene and the project.
Edit2: After some more finagling with how we were validating, saving is back to being quick. Here’s a snippet of what we were doing originally:
[SerializeField] Collider m_Collider;
protected virtual void OnValidate() {
m_Collider = GetComponent<Collider>();
}
And here’s the updated code:
[SerializeField] Collider m_Collider;
protected virtual void OnValidate() {
var colliderComp = GetComponent<Collider>();
if (colliderComp != m_Collider) {
m_Collider = colliderComp;
}
}
We have a Prefab pool that keeps prefab instances around rather than destroying them for garbage collection/speed reasons. Before we create an instance of a new prefab, we disable the prefab with SetActive(false), call Instantiate() and then enable back the prefab with SetActive(old_active_state). This ensures that no Awake, Start or OnEnable are called on that object, which makes it possible to call extra initialization methods before Unity calls theirs - this makes it possible we have the exact same flow no matter if the object was just created or re-enabled (we rely on determinism)
Even though the prefab ends up being in the same state from which it originated, it’s still marked as Dirty - so Unity thinks it’s changed. If we can mark it as “Force Not Dirty” - basically clearing the Dirty mark, that would fix all of our problems. I couldn’t find a way to do that though. Is this possible?
In the meantime, I am trying to work on a solution without us setting the prefabs to disabled/enabled but that requires quite a substantial code refactor.
Well, I just got an e-mail that my issue will be fixed in 2018.3.7f1
I am going to wait for it before digging deep into the project.