Not a Bug

Run-time rendering "hiccups" in a non-Bolt scene

blackmanatee 4 years ago updated by Lazlo Bonin (Lead Developer) 4 years ago 10

I love Bolt, but this bug is a killer and I don't know where to start, other than uninstalling Bolt completely.

I'm creating a flight game with a graph that tracks altitude. I haven't implemented ANY Bolt scripts into it yet, though I've used Bolt in other (totally separate) projects.

I've found a serious rendering "pause" that causes the whole screen to jar for just a frame or two, almost like a misaligned animation loop. I've checked the scene, deactivated almost everything, and it still persisted.  A couple of math-intensive calculations take place in my custom scripts (just a small exponential increase in altitude depending on height), but the scene (and scripts) work perfectly smoothly without Bolt. (I've built a duplicate project with only Bolt removed).

Please keep in mind: Bolt is NOT used in the scene, in any way, and no Bolt scripts are used in the project (yet).  The only difference between the working and "hiccup" version of the projects is that one has Bolt installed.

I had assumed that Bolt wouldn't be involved in scenes that didn't include it -- but then I found that the Variables Saver is running when I play the scene in the project with Bolt installed.

Here's a screen shot of the hiccups (the graph is the altimeter in the scene, showing altitude over time; the hiccups show up as altitude-bumps every second or so).  There are no errors in the console.

Any ideas?

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

Hi Blackmanatee,

Are you only getting this hiccup in the editor or also in a build?

It's possible that the actual lag you're seeing is Bolt's editor initialization. Because Unity is single threaded, some operations cannot happen in the background, and Bolt will lag a big on start when in the editor. However, this shouldn't be the case in a build.

Hi, Lazlo,

Your diagnosis is apparently on target. I'll paste the proof below -- it's definitely bolt, but it resolves in a built version. That's far from a cure, though. My scripts are very small, with simple math calculations, and they're running in "FixedUpdate" already. Perhaps the slow-down is because I'm using some (very limited) physics -- a simple upward force on a floating plane, to simulate flight.

It's not something I can really work with, so I have a couple of questions before I decide whether to uninstall Bolt and steer clear of it for my next couple of game projects:

  1. Would it help if I "translated" my simple scripts into Bolt graphs? My syntax is quite simple, but perhaps there are some optimizations that Bolt will provide if I use it for the flight mechanics.
  2. If #1 isn't likely to work, is there a way to disable Bolt while running scenes that don't use it (besides uninstalling Bolt)?
  3. If #1 or #2 aren't feasible, do you have any other suggestions for handling the thread-overload in Play mode?
  4. If #1 - 3 aren't workable, do you anticipate a Bolt update that might fix the problem -- either by letting us turn Bolt off, or reducing its demand on the thread when Bolt isn't used?

<<EDIT (10 min after initial post): I'm running Unity 2017.2, and I see that 2017.3 and 2017.3.1 have made some adjustments to the way threads are handled. I'm guessing it won't matter since you didn't mention it, but I'll let you know if the Unity update helps!>>

Thanks for any help or suggestions.  Here are the screenshots, offering definitive support for the connection between Bolt and the slowdown, which is fixed in builds:

1) BEFORE Bolt is installed -- this is a bare-bones project -- no other packages installed, just using scripts integral to the scene. Altitude shifts are smooth:

2) AFTER Bolt is installed -- same bare-bones project, no changes other than installing Bolt (and running the setup/configuration wizard):

3) AFTER Bolt is installed -- same scene as above, but running in a build -- glitches/hiccups are absent, and altitude shifts are smooth again:

Hi Blackmanatee!

I'm happy to hear this issue is absent from builds.

Unfortunately, there is no way to "disable Bolt" without uninstalling it. When it starts, Bolt has to preload many things, including editor resources, documentation, etc. This is what allows every operation to be snappy later on. This is not related to the scene you're in, but rather to the whole assembly reload. Therefore, the answer to every one of your questions is no.

I don't recognize your profiling graphs, but if you want, you can profile the editor to find exactly when the issue occurs. However, I already optimized this code many times, and I doubt it can get any faster now (with the exception of documentation loading, which will hopefully be faster in a future version; but it still happens on a background thread).

Is there a specific reason why you can't afford a lag of a few frames once when starting the game in the editor?

Hi, Lazlo,

A couple of things to note: first, the lines I'm showing aren't profiling graphs at all; they're part of the game where the player's goal is to keep the line within a certain range (altitude).

I've been trying to see which process is happening at those moments, but I don't see any particular script calls occurring then.

More importantly, though, the trouble doesn't happen just at the beginning of a level; I waited 30 seconds before doing anything, and the problem persisted from the start of the level until I pressed a key to start moving forward (30 seconds into the level).

I think maybe I didn't explain the graph well enough. Ignore the actual big curve and look at the little, regular ticks, like a heartbeat on an EKG (except smaller). Those are the glitches/lags, and they happen once per second or a little faster, *constantly.*  Here's a zoomed in version where I've circled the glitches:

It's jarring enough that it distracts from gameplay -- the whole airplane slams upward and downward by a few feet in just a couple of frames. I could never show an unbuilt version at a meeting or presentation, and show how the presets can be adjusted in the editor.

I've thought of one other way I could continue to use Bolt, though.  Is it possible to export a set of Bolt dll's, so they could be used in another project that doesn't have Bolt? For instance, if I created the GUI entirely in a Bolt project, then exported the necessary resources with Bolt scripts compiled as DLL's . . . and then had a usable (though un-editable) GUI in a project that does NOT have Bolt?

Thanks again for trying; it's a disappointment since Bolt is an excellent tool in so many ways.

Oh, I wasn't looking at the right spikes!

This looks like it might be due to GC spikes from the graph editor allocations. v.1.2.4 will have largely optimized those away, but it's still in alpha at the moment. If you want to test, copy your project and import v.1.2.4, maybe the issue will be fixed!

Thank you, Lazlo!  I'll give the alpha a try, and cross my fingers!

First, here's what I've found this morning: using the Profiler, it's clear that the spikes are tied to "GC.Alloc" related to a product I'm using -- a very simple real-time graphing plotter (the graph you're seeing as the HUD overlay in the screenshots above). It's called nGraph (or Graph Master), and I had assumed it was causing the problems -- perhaps because of a scripting problem.

That may still be the case -- even without Bolt installed, I see GraphMaster spikes, but they're not nearly as high (16 ms instead of the >66 ms shown in the screenshot below).  

With Bolt installed, the GC spikes are 4x higher (or more) -- see below).  I'll let you know if the alpha improves things.

Thanks again!

Hm, that's interesting, I wonder why these two plugins would be interacting.

I suggest turning on Deep Profile to be able to dig down to the exact method call causing the spikes.

Hi again, Lazlo,

I've purchased two new graphing assets, hoping to find one that worked with Bolt, but things are even worse than before. Bolt's GC conflict doesn't seem to be limited to that particular graphing program. :-(

The latest asset I've tried is called Smart Chart ($39, first released in December 2017, requires Unity 5.6.2 or higher). With Bolt installed, the frame rate and GC problem limits my PC to 10 fps (Pentium i7-6800 @ 3.4 GHz with 56 GB of RAM and a GeForce GTX 1070).

Here's a screen shot of the profiler, running in deep-profile mode as you suggested.  I'm disappointed that I can't use Bolt, but I'd love to try it again if the GC conflict gets fixed...

Quick update: I went ahead and installed the new alpha, since you mentioned it had an improved GC algorithm. Unfortunately, it doesn't seem to make a difference.  I'm still limited to 10 fps when running the graph demo from Smart Chart.  I hope you're able to track down the issue eventually, because I'd love to be able to use Bolt!

Here's the latest deep-profile readout, using Bolt 1.2.4 alpha:

Not a Bug

Hm, that's odd. This seems entirely unrelated to Bolt from the call chain.

I have found some results on Google that have a similar problem. Most mention that it was a problem with an asset they had purchased, and since this is the only report I've ever gotten like this, I suspect it has to do with the other assets in your project.





This post mentions it has to do with Resources.UnloadUnusedAssets. This is never called in Bolt, but might be called in your other plugins:


Other possible causes and workarounds:



I'll mark this as Not a Bug for now because I cannot see the relation with Bolt from your report.