Cannot Fix

Unity Slowdown When Variables Show In Inspector

HeathClose 3 years ago updated by Lazlo Bonin (Lead Developer) 3 years ago 5

I've discovered that having the inspector showing on any game object that has bolt variables slows unity to a crawl, and clicking off of it to a game object that doesn't have bolt variables in the inspector puts unity back to normal?  I used to think it was something weird so I would just restart Unity and sometimes it would go away, but now it's 100% of the time... It's almost unusable.  This happened even in 1.4.1b4 before I updated to 1.4.1b5.

Bolt Version:
Unity Version:
Scripting Backend:
.NET Version (API Compatibility Level):

In fact if I hide the inspector and click on another tab, or go full screen with the graph and add variables in the graph inspector, the slowdown stops.... its only if I see the variables in the inspector tab

I logged in to report the same issue, luckily there was a thread about it already.

I've just migrated from Playmaker and purchased Bolt to give it a go. Throughout the day I though I was doing something wrong as the sprites just stalled or crawled no matter how much speed I tried to assign to them. Then I noticed by accident that hiding the Flow Chart window speeds up the game to the full speed, but hiding the window every time I want to try out the code really isn't the optimal workflow.

I'm using Bolt 4.0f11dl'ed from the Asset Store on a high end 2018 Macbook Pro.

    Hi Ibuxal,

    Sorry you're experiencing this slowdown. The graph renderer has been massively optimized in v.1.4.0f8, so I'm surprised you're getting issues on a high-end MBP; there has been no report of lag since that update. 

    If your graph is an Embed on the machine, you might be running into the issue I described below. Converting it to a Macro might help. But if the issue truly is the graph rendering, then the only thing I can suggest is to break up the graph into smaller parts (with super units) instead of having one huge graph. 

    Also, if your game behaves differently with low FPS, it means you're not using framerate normalization in your logic. For example, if you make your player move by X amount in Update, make sure you pass X into a Per Second unit to make sure the framerate does not affect the speed.

    If you'd like to give more report/profiling data on the rendering slowdown, please start another thread, as this one is related to inspector/serialization.

    Working on Fix

    Hi HeathClose,

    So this is related to an age-old Unity issue that I was never able to explain.

    The Unity inspector window serializes and deserializes (saves and loads) the currently selected object every frame while it is selected. That can cause massive slowdowns when you have big objects, hierarchies, custom scripts, etc. As you noticed, that's not even technically required, as everything works fine with the inspector tab hidden away.

    Now, where this becomes especially problematic for Bolt is that in Bolt 1, the underlying serialization system is FullSerializer. FS is extremely powerful and versatile (which lets you create any variable type), but it's also notoriously slow. In Bolt 2, we are migrating all serialization to Odin Serializer, which is just as powerful but much faster.

    Regardless, this issue is something that should be addressed by Unity, in my opinion. I'll look around and see if anyone ever reported it as a bug or if there's a reason for it to be there. Speaking with the devs at Sirenix (Odin Inspector), they're running into the same issue and were considering to create a custom Inspector window that didn't reserialize at every frame to fix it.

    Cannot Fix

    Confirmed that Unity reserializing the object at everyframe is a longstanding, well know Unity issue and there's no way around it. The only thing we can do is improve the serialization speed, which we're doing in Bolt 2. Otherwise, using Macros is the best workaround to avoid reserializing the actual graph data.