0
Fixed

Lag spikes on graph instantiation

yan jun loh 2 years ago updated by Lazlo Bonin (Lead Developer) 2 years ago 14 1 duplicate

Hi!
I try to spawn Monster every One Second but found a performance issue...

Every Time I Spawn a new Enemy, my game will Lag... 

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

Duplicates 1

Pending Review

Seems to be related to FullSerializer, I'll do some more profiling and look into it.

I also have the problem and perform quite worse on android, and it may cause memory crash on ios if 5 or more big graph initialize in one frame.

FullSerializer is powerful but also with the largest gc when deserialize the data.

Hope for a zero gc resolution.

By the way, I also prefer a bultin method of compare or merge the marco.asset(or flow.asset),even only compare the inside json string(pretty print)。 Have any idea?

+1

That is already a documented bug. It is The next on the list of things to do in the roadmap. Meaning it'll be updated pretty soon. 1-2 weeks has been the average. So you won't be waiting too long on this. 

http://support.ludiq.io/topics/392-roadmap/

OK,Wait for good news

Yes, this is the #1 priority after the tutorial.

By the way,I also prefer a bultin method of compare or merge the marco.asset(or flow.asset),even only compare the inside json string(pretty print)。 Have any idea?

You can use the little cog menu on the component and click "Show Data" to see the JSON data of a machine or macro.

I tried that it tell me to repair the Visual Studio and nothing more happened.

+4

Back to work on this. I got a promising system in place, but I still got a few bugs to iron out.

Basically, once this is done, instantiating graphs will skip serialization altogether and deep clone objects in memory. This won't be a zero-alloc operation, but it will be orders of magnitudes faster and more efficient. 

The only allocated memory will be the memory required for the graph copy object, without any of the FullSerializer overhead.

+1

More updates:

I currently have the main fix in place. You can expect major reductions in both GC allocation and instantiation time in version 1.1.2:

  • On average, 3-4x less GC allocation
  • On average, 5-7x faster instantiation

I'm working on additional small improvements to try to get that operation even faster and leaner on the memory. 

Be aware, however, that there is no perfect solution, because we're instantiating new game objects, with new grahps, and therefore they will always allocate at least as much memory as it takes for the graph objects themselves. If you want to avoid allocation altogether, for example on mobile, you should use object pooling (any traditional method should work), which is a common requirement when coding instantiation for mobile and console games.

Oh and one more thing: while profiling, I also significantly reduced general GC allocation (often 10x less) per frame. The only remaining alloc should be the cost of boxing value types, which is small but impossible to avoid.

I think the key is to make the cost of json(or other config file) phase gc to almost zero. The mem alloc of  instaniating gameObject or the asset like graph objects is impossible to avoid, we can use the pooling to avoid. But just the api should open that can replace the inner runtime data, so that we can use pooling object or config file flexible.