0
Fixed

Bolt is allocating a lot of memory per frame

Carlos Castro 2 years ago updated by Lazlo Bonin (Lead Developer) 2 years ago 12 1 duplicate

Im using Bolt 1.4.0f6 with Unity 2018.2. I noticed Bolt is always allocating memory. A blank scene with a cube using a  flow machine, will still allocate memory. Is this normal? The tool is marketed as close to zero allocations. I finished the tutorial, if I load level 4 it will allocated like 32kb per frame. And will invoke the GC collector frequently. I've attached a screen shot for a new scene with a cube with a flow machine with an empty update. Also attached a screenshot of how it looks with Level 4 of the tutorial.

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

Duplicates 1

More detail about level 4 of the tutorial.

Pending Review

I'll look into this. A minimal amount of allocation due to boxing is possible, but 32k is way too high.

Can you enable deep profiling and try to dig down to the root cause?

Will try that, but should an empty flow machine allocate 0.6kb per frame? I tried that with bolt 1.3 and got 0 allocations with empty machines. Another thing, I downloaded from forums the flappy project.


Its allocating 12 kb per frame. Could it be something related with enabling live edits in 1.4? Running PC build still allocates same amount. 

+1
Working on Fix

This sounds like a buggy regression indeed. An empty flow should not allocate anything. I'll look into it! 

+1
Fixed in Next Version

Found the cause! The reworked infinite-recursion protection system in v.1.4.0f6 did not properly free its pooled instances. Allocation is back to zero per frame on an empty flow. The fix will make it into v.1.4.0f7 which I hope to publish today.

So as a follow-up to this, I did a quick test. I isolated my most intensive macro in a scene by itself (the player controller) and saw that it was allocating about 1.4KB per frame by itself. (It's multiplayer, so there are 4-8 of these in a scene). Which seemed kind of excessive, but I'll admit I don't really understand the GC all that well. 

Still, it's not a super-complex macro, though it is a state machine. So as a test I copied the whole macro over into a C# script, function for function (honestly the only reason I could even do that is the fact that I've been using Bolt for a few months and it's taught me a lot). And I found that the exact same script (more or less, took a little fiddling to replicate the state machine logic) had 0 allocations. 

Also, just to be clear, that's in both editor and a stand-alone player build. But it still seems like there's an awful lot of GC allocation happening on some of my macros. I tried caching all of my component references in object and graph variables, but that didn't seem to have any effect. Is this just an unavoidable consequence of using Bolt, or is there something more happening here?

Fixed in Next Version

Hi GhostAegis! Chances are this is related to this issue:

https://support.ludiq.io/communities/5/topics/2188-bolt-is-allocating-a-lot-of-memory-per-frame

1.4 should actually allocate *less* memory per frame than 1.3. We're moving towards the flat-zero mark with code generation and strong-typing in Bolt 2.

Okay! I'll give it another try when the fix is released and report back.

Bolt 2 sounds increasingly amazing, I can't wait. I have to say I was really pleasantly surprised to find how easy it was to recreate my macro in C#, using Bolt has really taught me a lot. Prior to picking up Bolt earlier this year I had never really coded anything, as I always found it daunting (I'm an artist by trade, so code was never my thing). That said, I did immediately miss Bolt. It made me doubly appreciate how awesome the variable system, custom events, and state machine systems are.

So the memory allocation problem does appear to be fixed with the update, but I'm still seeing a nearly 4x increase in performance cost when moving from 1.3.0 to 1.4.0f7  (I'm on Unity 2018.1.9f1). Up from ~6 ms to >22 ms. 

I can make a separate thread if you'd like, but it looks like there are still some pretty serious performance problems with 1.4 that mean I have to remain on 1.3 for the time being. If I could just get these macros to stop randomly unloading themselves when I load their scenes that wouldn't be so bad...

If you can point me in the direction of any specific information I can gather to help you narrow this down I'd be happy to do it.

Hey GhostAegis, sorry you're seeing this regression. Yes, please start another thread and be specific about where you're getting the slowdown (on initialization? on instantiation? every frame?). Also include screenshots of deep profiling, it's the only thing that will help me pinpoint the source of the issue.