Use object pooling

[j9liu]

We currently create and destroy numerous CesiumGltfComponents and UMaterialInstanceDynamic objects throughout the lifetime of the program. Unfortunately, this accumulates in a large use of FNames over time (and potentially other performance / memory drawbacks we have not yet discovered). This was partially solved in #1423, but the FName out-of-memory crash can still happen even after this fix, as noted on the forum.

The real solution would be to create and use object pools. Beyond materials, this could be beneficial for components or meshes, too. That way, we can avoid infinitely accumulating FName objects.

[spikhoff]

Excessive creation and destruction of CesiumGltfComponents and UMaterialInstanceDynamic objects can lead to a significant increase in FName objects, impacting memory usage and performance.

Solution: Leveraging Unreal Engine's Built-in Pooling Mechanisms

Unreal Engine provides robust pooling mechanisms that can effectively address this memory issue. By utilizing these features, you can significantly reduce the creation and destruction of objects, improving performance and memory efficiency.

Key Points:

• Component Pooling: Unreal Engine offers built-in component pooling capabilities. Use the appropriate component pool manager to acquire and release components as needed.
• Material Pooling: For UMaterialInstanceDynamic objects, consider using the UStaticMeshComponent's material pool or creating a custom material pool if necessary.
• Custom Pooling: If you have specific pooling requirements, you can create custom object pools using techniques like reference counting or a dedicated pooling class.

Additional Considerations:

• Performance Profiling: Use profiling tools to measure the impact of pooling and identify areas for further optimization.
• Object Lifecycle: Ensure that objects returned to the pool are properly cleaned up or reset before being reused.
• Trade-offs: While pooling can be beneficial, it may introduce additional complexity. Carefully evaluate the trade-offs for your specific application.

By effectively utilizing Unreal Engine's built-in pooling mechanisms, you can significantly mitigate memory issues and improve the performance of your application.

[kring]

@spikhoff that reads as AI generated (my apologies if I'm mistaken, but references to "your specific application" jump out at me), but it's a reasonable summary nonetheless. Unreal may already have an object pool of some sort, so I'd look for that before implementing something like the ObjectPool class. In any case, the most challenging aspect is likely to be figure out how to "reset" Unreal UObjects to prepare them for reuse. I wouldn't be surprised to run into Unreal bugs or race conditions when trying to do this, since rapid reuse of UObjects at runtime is not a very common use-case as far as I know.

[spikhoff]

Hey @kring and folks,

Just wanted to give a heads-up about the recent post. I've been hacking away at it, and to be honest, I've been using some AI tools to help out here and there.

I know some of you might be raising an eyebrow at that, but trust me, it's not about replacing human ingenuity. It's about being efficient and trying out new stuff. I've been keeping a close eye on the AI-generated stuff and making sure it fits in with what we're doing here.

If you have any questions or think something's off, don't hesitate to shout. This is all about open communication and transparency.

[kring]

Ok, thanks for the heads up @spikhoff. For the development we do ourselves, we currently have a policy against using code-writing AI tools. Not because we're worried about it replacing human ingenuity, but because the ownership (copyright) of the resulting code is still at least a little bit uncertain. We want people to be able to rely on our open source products in a wide variety of circumstances, so we are very cautious about this kind of thing. I'm not currently certain if and how that policy applies to external contributions, given that such contributions are covered by the Contributor License Agreement, but am trying to find out.

[spikhoff]

Hey @kring,

Thanks for bringing up the AI tool policy. It's a good point to consider. Copyright can be a bit of a pain, especially in open source.

Ultimately, the decision on whether to allow AI-generated code in contributions is up to the project community. If there are legal concerns, we need clear rules to keep things running smoothly.