Hi Guys! I have a really simple question in all reality but I was really curious to see what people think the best way to do this is.
As you can see in the image, I have two blueprints where I want to send a message to my HUD. In one instance I get my WidgetManager reference by going through all the “nesting” and getting the message sent without setting a variable. But in the other option I have the same process but then I set the variable to be called at a later date.
For the first option I would assume the ue4 garage collection would get rid of everything after sending the message. So besides the code running and the little space it takes up in storage, the game wouldn’t need to save the variable.
Then on to the second option, the code does all the work once. It doesn’t need to jump through all the hoops once its set the variable at the start. But weather this would affect memory or anything else I wouldn’t have the slightest idea.
I feel like the answer might just be that it doesn’t matter but I’m the micromanaging type that think about if I write all of my blueprints in the correct way I could squeeze out just a once more of performance. So I was really curious to see what everyone’s opinions are.
As for memory, they are more or less equivalent. The intermediate variables are probably not even garbage, they’re probably just kept on the blueprint evaluation stack, and go away when the function returns.
As for lifetime, if you delete the GUI, then the widget you’re holding on to a reference to, cannot be deleted, so there is a difference there.
Updating a message in a GUI is generally quite infrequent – either once every few seconds, or, if you’re crazy, once per frame – so the runtime cost of retrieving the pointer each time isn’t terrible. But you could save a few cycles by caching the value, assuming you only do it once, when you create the widget/gui. If it’s really a problem, another option is to write that bit in C++.
The long chain of getting the value is sometimes inconvenient in the graph editor, so you could collapse that to a macro or function or perhaps sub-graph, as an alternative, if you stick with the “dig out the value each time,” which is the most robust to avoid memory leaks and react to the value changing.
Wow, Thank you for all that info. Its actually crazy how much I was able to learn just from that greatly worded little bit of text.
I just want to confirm what I’m thinking. It’s not a set standard but most of the time it’s a case by case basis. Like my HUD that should never be destroyed or spawn in again, I could just set the reference and call it a day. But in the case where I spawn, destroy, and spawn something over and over it’d be best to go back turn that into a macro to avoid memory leaks?
The macro doesn’t avoid the memory leaks, it just cleans up the blueprint graph. What a macro does, and what those same nodes do if you were to just put them into the main graph, is the same, it just looks nicer and is easier to work with when graphs get big.
Yes, an object that is spawned, and then temporarily used, and then all references go away, will be collected and not leaked. It’s almost always better to hold on to a single object and re-use it, if you can, though, if you’re really worried about low-level performance. There are some kinds of loops where this really helps, but for simple “UI that changes once in a while,” it won’t make a difference.
