Hello All,
What happens to PrintString in a shipping build? I imagine it still gets called, just doesn’t get displayed, just trying to make sure. This isn’t anything pressing, just wanting to know if the packager strips them out, or just suppresses them?
Anyways, thanks everyone on these forums, I wouldn’t have gotten half as far as I have if it wasn’t for you guys! Sorry about the random questions :).
yes, I believe so.
If you want to see if it works after package, you can do a debug build, it would be the same but leaves consoles and prints intact.
Thank you for the reply!
I know that they are present in a debug build, I’m wondering what happens to them in a shipping build. I know that they don’t get displayed, just wondering why they don’t, whether they are suppressed or stripped? I want to make sure I get rid of any unnecessary Print calls if they are just suppressed :).
My gut feeling is stripped, as blueprints are scripts that can be preprocessed before you send to compiler, my guess is during shipping build, print nodes are just simply skipped/stripped and do nothing.
Only actual dev can answer this unless you want to trace C++ code.
It’s really hard to find out an answer to this question, does anyone know? Because if removing them will reduce APK package size / performance for android it’s best remove them, but if they automatically get removed then it’s just a lot of extra work to remove all the ‘print string’ nodes in the final build (and makes future debugging harder, for updates etc)
It looks like the body of the PrintString function is simply omitted so the function will still get called but do nothing. Removing them from Tick events and anything else that gets called every frame might help a little but I would do this as one of the last optimizing steps as it probably ain’t gonna make much of a difference compared to other tweaks.
PrintString functionality is called inside of the collapsed #if directive in the attached picture. As you can see, that block is not called if the shipping configuration is shipping or test. A similar method of excluding functionality in shipping builds is used for many other debugging functions.
So, just to clarify, you can put a million print strings for debug and error checking purposes in your project but when you actually package it for shipping, the player will never see them. Without having to change anything in C++. Is that right?
Yes, but a million function calls still have a performance cost.
void UKismetSystemLibrary::PrintText(UObject* WorldContextObject, const FText InText, bool bPrintToScreen, bool bPrintToLog, FLinearColor TextColor, float Duration)
{
#if !(UE_BUILD_SHIPPING || UE_BUILD_TEST) // Do not Print in Shipping or Test
PrintString(WorldContextObject, InText.ToString(), bPrintToScreen, bPrintToLog, TextColor, Duration);
#endif
}
There is still a lot of overhead just getting to this function via the reflection system. AS the node still get called, they hit this function, which simply returns. But looking up a function in a linked list by name burns a cache line for each node in the list. A proper study would require timing 1 million calls or so in a tight loop and hold a stopwatch and see how long it takes.
Most likely though, if you’re fine with performance, then anyone who likes the app would rather you spent your time on the next app rather than worrying about things that have not been reported as a problem.
Cheers,