koobas.hobune.stream
Frequently change TextMeshPro text without garbage allocation?
Is there a way to frequently change a timer display created with TMP, without it generating garbage?
I'm currently using TMP.SetText(), which is supposed to not generate garbage, but it does.
Are you profiling it in the editor or from a build? I believe that function does create garbage when running in the editor but not in an actual build. This is because in the editor calling the SetText function will update the .text property of the TMP object, whereas in the built player it does not.
Profiling in Editor.
Not aware of ways to profile a build.
In the build settings you need to check the boxes for "Development Build" and "Autoconnect Profiler". If you then build and run with the profiler window open it should connect. There are quite a few things under the hood that are different between running in the editor and running a build, profiling a build will give you a much more accurate look at how your games performance.
If your SetText looks like this:
SetText( $"{ minutes } : { seconds }" )
Then you may be interested in knowing how to code timers without creating new strings every frame
// Note: I'm not aware of TextMeshPro details. This is general approach I use when dealing with UI components.
Hey Andrew: I'm doing it in a weird way... any problems with this?
void UpdateSectorTimeHUDs ( ) {
_val = Time.realtimeSinceStartup - _sktrStartTime;
if ( _val < 1 ) {
tmpTimerL.SetText( "00{0:3}", _val );
return;
}
if ( _val < 10 ) {
tmpTimerL.SetText( "0{0:3}", _val );
return;
}
if ( _val < 100 ) {
tmpTimerL.SetText( "{0:3}", _val );
}
else { print("time is being reset because took too long" );
_sktrStartTime = Time.realtimeSinceStartup;
}
}
Yes, methods where you provide some kind of format and (uint/ulong etc) value are most often than not just equivalent to writing:
SetText( _val.ToString(format) )
Where ToString() method allocates a tiny string object every time you call it.
THAN$$anonymous$$ YOU!!! This bit of insight is invaluable!!!
$$anonymous$$y general idea to prevent this is to generate ALL possible strings for this counter when scene/game starts to a generic hash table (dictionary). And on every Update after that just reference one you need.
To prevent creating a medicine that is worse than the actual ill you should estimate size of your output cache for given counter format string.
For "hh : mm : ss" it would be:
24h * 60m * 60s = 86400 combinations
86400 * "00 : 00 : 00".Length * sizeof(char) = 1 036 800 bytes = 1$$anonymous$$B (too much)
As you see from the math this can go south easily when your format string is too long and produces too many permutations. So to optimize that - just break this format string into few separate UI pieces (hours,seconds etc using separate UI components) and number of variations will drastically fall to just few hundreds of them and will take no more than just few $$anonymous$$B of memory.
"mm" and "ss" is just 60 * "mm".Length * sizeof(char) = 240 bytes (good)
I wrote an implementations + example to simplify the whole thing if you want: www.github.com/andrew-raphael-lukasik/CacheStrings.
I've had a look at this. But am having trouble unwinding it (mentally) for how I'm doing things with just seconds and .000 ti$$anonymous$$gs for a very fast game.
Not your fault. I'm not a coder. So anything more complex than my example above is tricky for me.
