Проблема 100% в коде, которого нет, поэтому я вдамся в гипотезы. Начну с самого хардкорного и закончу тем, что по лайтовее.
1. Авторазмер
Возможно, у вас есть скрипт, который при каждом изменении текста пытается отмасштабировать не шрифт, а границы самой компоненты. Проблема в том, что при любом изменении элементов интерфейса юнити перерисовывает вообще весь затронутый канвас. Речь не о свойствах типа цвет, а о перемещении и изменении границ.
Если у вас такая проблема, то стоит оставить текст в покое и изначально сделать задел по размеру текста на будущее.
Сюда же можно отнести перерисовку других элементов для ScrollView или использование UI Layouts.
2. GetComponent
Возможно, вы используете GetComponent. И делаете это довольно часто. Что-то типа такого:
public void SetupText(string textToDisplay) {
GetComponent<TextMeshPro>().text = textToDisplay;
}
Парни с ютуба часто советуют такой треш. Под капотом этот метод довольно тяжёлый и будет тем тяжелее, чем больше компонент на объекте и чем больше раз за единицу времени вызывается.
Если это ваша проблема, то рекомендую заранее кешировать. Например, сделать это на старте:
private void Start() {
someTextComponent = GetComponent<TextMeshPro>();
}
А ещё лучше просто создать видимое инспектором поле и руками туда передать ссылку.
[SerializeField] TextMeshPro someTextComponent;
3. Частота вызова
Ещё один треш, которому учат в интернете - менять что-то или проверять не тогда, когда это нужно, а просто в том же Update. Проблема здесь кроется в множестве "холостых" вызовов.
Если у вас обновление текста происходит всегда, а не только при необходимости, то стоит подумать лучше над архитектурой.
4. Размер текста
Особенность компонент пакета TMPro ещё в том, что метод SetText или аксессор .text не только просто берёт и вставляет, а ещё проводит довольно большую работу под капотом. Если у вас большой текст, вы реально увидите просадку даже на компе, не говоря уже о мобилках. Такая проблема очень актуальна. Например, если вы скриптом или твинами делаете постепенно появляющийся большой объём текста для диалога в игре.
Решением в данном случае будет либо анимация, либо написание своей реализации нужной компоненты.
Если среди проблем вашей нет, приложите код. Желательно весь, но в контексте задачи интересна цепочка вызовов от события к присвоению текста.
PS. на будущее, FPS проекта в редакторе и FPS игры в билде не одно и то же. Сделайте простой счётчик FPS и посмотрите на ситуацию в игре.
кадры прыгают от 0 до 20 фпс. понял что проблема не в тексте, а в редакторе, после перезапуска юнити если в режиме плей войти сменить фокус с окна игры на редактор, кто фпс резко просаживается, и как бы не перезапускать игру, это не решить пока не перезапустить юнити 
