As a developer it’s incredibly important to collect feedback from the software before making modifications. Often you can get feedback from logs, UE console commands (Stat …), hardware monitoring, hooked debug monitoring (memory, network usage etc.)
Only then can developers pinpoint the issue aka bottleneck, as one bottleneck k*lls the performance of the entire system. It’s the weakest chain. If you don’t identify the bottleneck through logged data, you are optimizing with little effect.
This bottleneck is important to identify in your current situation because random optimizations don’t get rid of the direct problem. On the software side, through methods mentioned, you can figure out what parts of the code cause the problem, before you attempt to fix them, re measure, and repeat optimization.
On the hardware side, I mentioned that some problems like heat (battery, CPU heat mostly) are actually a hardware problem. This could be a problem with the cooling method or the electrical circuit of a specific device entirely and it’s out of your control. Devices should also implement their own safety guards against overheating and such. Often that results in devices reducing their processing speed or shutting down in attempts to operate within their own “safe” specs.
The thing is, everyone runs different hardware. It’s not just a matter of how fast their device is. How it’s built affects how hot it becomes. A bad hardware model won’t run properly, and a developer doesn’t have access to all models to test them. Feedback from users to the developer can be useful, but can’t guarantee a fix for hardware problems.
Referring to the above I wrote, other devices (your customers) might not have the overheating problem. It can just be your device.