Gamua / Starling-Framework

The Cross Platform Game Engine
http://www.starling-framework.org
Other
2.86k stars 822 forks source link

Too many MeshBatch instances #1023

Closed hardcoremore closed 6 years ago

hardcoremore commented 6 years ago

https://github.com/Gamua/Starling-Framework/blob/365ece4199385d2e197219a2fa57114b42cb818d/starling/src/starling/rendering/BatchProcessor.as#L202

Hi Daniel,

BatchProcessor keeps creating MeshBatch instances all the time even though I do not create new display objects. Can you implement pooling for this please. Because it is triggering GC so much and it is affecting performance. Take a look at the Scout profile screenshot:

https://ibb.co/n5ZMcx

It creates almost 2000 objects because of that.

Is it possible that MeshBatch is not returned to the pool properly?

Thanks,

Caslav

PrimaryFeather commented 6 years ago

Hm, that's weird — those MeshBatches actually are cached, so there shouldn't be any more created after a while.

Could you send me that complete Scout file maybe?

hardcoremore commented 6 years ago

Yes of course. Thanks so much for looking into this.

Here is the link to the Scout profile:

https://goo.gl/HHgM6h

In this Scout profile I have played my platform level until I have completed it (collected everything and destroyed everything that can be destroyed). You can see exactly on the 6:34 that I have stopped playing level so you should look everything before 6:34

Thanks.

PrimaryFeather commented 6 years ago

Thanks for sharing! I'll have a look as soon as I can squeeze it in!

hardcoremore commented 6 years ago

Thanks so much Daniel!

hardcoremore commented 6 years ago

Hi Daniel,

Any news about this issue?

PrimaryFeather commented 6 years ago

I just had a look at it — sorry for the delay!

I believe that what you're seeing are the MeshBatches that are being recreated after I'm purging the pool. Starling does that from time to time to make sure memory does not endlessly stack up.

The problem with batching is that a simple change in the scene might cause the MeshBatches to fill up completely different. For example, in one frame you might have a huge batch "10", but a small batch "11"; then you insert one additional display object that breaks batching, and suddenly "10" is the small one and "11" contains a lot of objects. This means that "10" has a lot of reserved memory that's suddenly not needed any more. If that happens often, you'd run into memory issues. So I'm trimming the batches from time to time.

However, the frequency with which I'm doing this is more or less an arbitrary value. You'll find the two lines responsible here: Painter.as#L570. Please remove those lines or change the numbers, and then try again.

hardcoremore commented 6 years ago

Hi Daniel,

If I remove both those lines in Painter class I get waaaay less allocations and everything seams fine. But what should we do now about it?

Can you make it an optional with static var like Starling.enableBatchTrimming = false or something like that. I would like to use Starling from master branch but with option to disable batch processor trimming.

Thanks a lot,

Caslav

PrimaryFeather commented 6 years ago

Thanks for trying it out — I'll think about something! Probably a static property like that will do the trick, yes.

PrimaryFeather commented 6 years ago

I just added such a method to the Painter! Use it like this:

// disable altogether
Starling.painter.enableBatchTrimming(false);

// change interval
Starling.painter.enableBatchTrimming(true, 500); // trims every ~500 frames

I hope that helps!

hardcoremore commented 6 years ago

Awesome, thanks!