BuildPipelineInterfaces causes streaming hickups (>5.6)

Hi,

The new BuildPipelineInterfaces is a lot neater than the old attribute way, and I do really like it. However, recently after upgrading to 5.6 I was investigating scene loading performance in the editor and came across this:


In this scene a lot of neighboring scenes are streamed in. The spikes (>200ms) come from BuildPipelineInterfaces.InitializeBuildMethods. For _every_ scene that is loaded this is called again. This method scans all unitys & your assemblies and uses reflection to find the right build interfaces - meaning the larger our project gets the worse this will be.

This makes games with level streaming in editor really laggy and hard to play. It's sucks to have all of these well oiled systems working together to create a smooth streaming experience, but then only to have all that undermined because the build team didn't optimise their callback system.

The biggest problem is that InitializeBuildCallbacks is called for every scene while really it seems like it should only happen in the first scene. I've reported a bug (case nr 933800)

If I can go on a somewhat larger rant here though, this way of handling callbacks has always frustrated me. Take a look at profiles like these:



The marks indicate systems doing the same type of reflection over your code looking for attributes. This I believe is an important cause why unity performance degrades for larger projects. This attribute scanning happens every time you enter play mode and every time you recompile code. Actions users perform many many, upwards of hundreds, times a day (Relevant XKCD). It sucks more and more the larger projects get, and especially now that more of the engine is being moved to C# this won't scale. In an ideal world these callbacks would be cached in the AssetDatabase and updated incrementally. Also having some kind of shared UnityReflectionManager that all the subsystems could talk to could help.

All in all, I really hope something can be done about BuildPipelineInterfaces urgently, and longer term it;d be really great if something was done about this way of handling these types callbacks generally.

Best regards,
Arthur

 

I submitted "EnterPlaymode" bug-reports too, here are the links for completeness:

BuildPipelineInterfaces causes slow EnterPlaymode performance
https://forum.unity3d.com/threads/c...causes-slow-enterplaymode-performance.484482/

Editor performance of Open/SaveScene and EnterPlaymode
https://forum.unity3d.com/threads/5...e-of-open-savescene-and-enterplaymode.447500/

 

Can we expect a fix for this in in 5.6.4p2 ?

 

Can we get a fix for this in 5.6 soon?

 

Can we get a fix for this in 5.6 ? Cause we don't want to upgrade to 2017 for now

 

Fix for 5.6.6 would be appropriate (If not already done!). The version 5 was really pain to use until 5.3.3, and now it is again a pain with 30 sec. start/play time. I have 6500 GameObects in my scene, disabled all not necessary GameObjects by splitting them in a scene and unload that scene. My scene should start now in 5 sec. I or we don't asking for features for the version 5.6.6, but at least for a 'working' version. I don't know how to develop the game with 30s iteration.

Has anyone experience comparing the play start time in Unity 5.6.6 and later versions? I don't need anything from the later versions, but speed.

Is it enough to drop all the code outside the Standard Assets folder to the Plugins folder to get rid of reloading the assemblies?

 

There's no more patches coming. Unity's 12 month commitment to patches for 5.6 ran out several months ago. 5.6.6 was the final 5.x release.