is it bad for the performance to have a lot of code in the user widget blueprints?
It’s impossible to say how something performs without testing it. You would have to measure the impact of your solution to know if it’s good or bad. Blanket statements like “you should never use…” are not a good guide to follow.
1 Like
Hi, generally speaking, as far as I know the amount of code you have does not have any impact on performance, compile times might get slower though. If you have a lot of code that is executed every single frame (in the tick event or from some binding that executes every frame), that can affect performance.
Therefore I find it a good practice to build things event driven. For example, if you would like to display the player health in a widget, then a bad way of doing things would be to query the health every single frame. Instead you could create an event dispatcher in the player and call it when the health changes. Then bind to that event dispatcher in the widget, and from there update the health shown in the widget.
Also you can always prototype first, then profile the performance and optimize from that (e.g. rebuild problematic parts to be event driven, or move them to c++). The profiler can show you the time individual blueprint functions and events take up.
Build it.
Run it on the target hardware.
Measure it.
If it hits your target frame rate, it’s not bad.
If it has too big a measured impact, it’s time to start profiling.
First, cut out ALL the code, to get a baseline of how much the code in question costs. That’s the absolute best you can do, if you optimize only that code.
Then, look at the profiler for which parts of your code end up costing the most time, and figure out how to not do those things – pre-compute, change design, use better implementation, or just cut it out entirely.
This is the core of performance engineering. There’s no shortcut, and nobody can know what your particular goals are or whether your particular code will hit those goals or not, but you.
1 Like
Others gave great replies.
If you do simple and straightforward actions, then it performance shouldn’t really matter, but it’s better to profile if you notice any issues rather than worrying about performance before you’ve even made anything.
It’s worth keeping in mind some Widget functions are configured to be cosmetic only, which means they might run multiple times in the background as the user interacts with the UI. Ideally you don’t want to add anything gameplay-specific or expensive, but that’s also something easier dealt with after it becomes an issue.