Garbage collection on mobile. Pooling required?

Hi all. Here again with performance questions for mobile. I'm currently in the position where KlangM runs great on my phone the first couple of levels, but when the demo resets I do see that the same levels runs slower than before. As the game's currently very small, and I unload audio between levels, I don't get the impression this is related to memory.

However I am creating and destroying a lot of objects during a level, and I'm wondering if these framerate drops can be credited to me creating and destroying more objects than what the garbage collector can keep up with, even between levels? Also when I look in the debugger I do see that the UID of assets just keeps rising even if I delete objects regularily, and move between layouts. My gut feeling tells me this can't be good. It's almost like objects never truly gets wiped from memory...

I did see very extreme cases back when I still wasn't pooling the dynamic lightning.

When I made a system that only created those assets once, it greatly improved performance on mobile. Is pooling everything simply considered mandatory practice on mobile?

If I recall correctly construct 2 automatically handles object pooling for you. Whether you can improve on the built in pooling with a custom solution depending on your use case is up in the air, you'd have to run some tests. As for the UIDs constantly increasing, that's completely normal behavior. UIDs are to be used as a replacement for reference types in traditional languages like C#. A newly created object means a new uid. They are not tied to the true memory location of the object however, so even if you create a new object, destroy it, and then create it again, the new object might be pooled internally by construct and reuse the same js object, but it will be given a new uid otherwise that would make no sense. At the event sheet abstraction level it is for all intents and purposes a completely new object, even if the back end has pooled the internal object to save GC time at the lower level.

Are you sure it's not just your events leaking objects? As in, the object count constantly increasing over time?

It's normal for UIDs to keep increasing, Construct just increments the global UID counter every time it creates a new instance, so the current UID is meaningless in terms of performance.

Unless you have specific measurements pointing at a specific cause like GC, it's a waste of time to start guessing about things like that. I'd first try C2's own profiler, but if that doesn't help pin it down you can try running a performance profile with Chrome's dev tools to see where most of the time is going. (Make sure you don't minify so the names are readable.) You can save and share profiles so I can have a look at anything you record and see where most of the time is spent in the engine.

Also modern mobile devices aren't really that special compared to desktops any more, if there's a real performance difference you should be able to reproduce it on desktop too, albeit with higher measurements (e.g. 60 FPS but a change in CPU usage or something like that).