Efficiency when changing text

[qiveal]

I sometimes in my project have to switch maybe like 6 texts at once change all of their texts (because of different languages) and see if we have to change the fontstyle from bold to normal. This can create performance issues and I thought I knew how to do this right, however i’m experiencing performance issues (please note I rather use normal text instead of TMP). I have been using stringbuilders for a lot of this stuff, however are there any other better practices when dealing with text efficiency?

[JeffDUnity3D]

@qiveal

I sometimes in my project have to switch maybe like 6 texts at once change all of their texts (because of different languages) and see if we have to change the fontstyle from bold to normal. This can create performance issues and I thought I knew how to do this right, however i’m experiencing performance issues (please note I rather use normal text instead of TMP). I have been using stringbuilders for a lot of this stuff, however are there any other better practices when dealing with text efficiency?

Please share the code that you are using. What performance issues?

[Kurt-Dekker]

@qiveal

This can create performance issues and I thought I knew how to do this right, however i’m experiencing performance issues (please note I rather use normal text instead of TMP).

Six strings causing performance issues?!!! I am highly skeptical of that, unless they are massively long multipage strings.

@qiveal

any other better practices when dealing with text efficiency?

First, make sure you’re not chasing ghosts

DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window → Analysis → Profiler

Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

https://discussions.unity.com/t/841163/2

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Notes on optimizing UnityEngine.UI setups:

https://discussions.unity.com/t/846847/2

At a minimum you want to clearly understand what performance issues you are having:

• running too slowly?
• loading too slowly?
• using too much runtime memory?
• final bundle too large?
• too much network traffic?
• something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

[qiveal]

@Kurt-Dekker

Six strings causing performance issues?!!! I am highly skeptical of that, unless they are massively long multipage strings.

First, make sure you’re not chasing ghosts

DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window → Analysis → Profiler

Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

https://discussions.unity.com/t/841163/2

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Notes on optimizing UnityEngine.UI setups:

https://discussions.unity.com/t/846847/2

At a minimum you want to clearly understand what performance issues you are having:

• running too slowly?
• loading too slowly?
• using too much runtime memory?
• final bundle too large?
• too much network traffic?
• something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

@Kurt-Dekker

Six strings causing performance issues?!!! I am highly skeptical of that, unless they are massively long multipage strings.

First, make sure you’re not chasing ghosts

DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window → Analysis → Profiler

Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

https://discussions.unity.com/t/841163/2

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Notes on optimizing UnityEngine.UI setups:

https://discussions.unity.com/t/846847/2

At a minimum you want to clearly understand what performance issues you are having:

• running too slowly?
• loading too slowly?
• using too much runtime memory?
• final bundle too large?
• too much network traffic?
• something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

Thanks for the reply. I think I will just try to see how it works when it’s built.