The processing of the text (parsing and layout) is CPU related and identical regardless of whether you are using an SDF or Bitmap font asset.
Using Signed Distance Field or Bitmap affects rendering performance and GPU where between rendering plain white text using an SDF Shader or Bitmap shader the performance is virtually the same. As you add Outline, Underlays, Glow, etc. the shader has to do more work per pixel but again the performance differences are marginal.
In terms of performance, take a look at the Benchmark (Floating Text) example scene. This scene reflects the performance of both the text processing and rendering.
By default 250 static text object and 250 dynamic text objects are instantiated (total 500) where these 250 dynamic text objects are updated each frame. This scene includes a frame counter to display the frame rate.
You can change the # of text objects in the test scene to check the performance differences between Development Build, Development Build + Auto Connect Profiler, Development Build + Auto Connect Profiler + Script debugging and Release build. You observe performance differences between all of these where Development + Profiler (Recording) and Script debugging is the slowest.
For instance, on my Galaxy Tab A (SM-T510) using this test scene with 1000 static text objects + 1000 text objects being updated each frame, I get the following results. Note that the rendering / GPU impact on the fps is the same between these. We are only comparing CPU performance overhead in the text update process.
Development Build + Profiler (Recording) + Script debugging ~ 7fps
On that frame 745 text objects were updated which took 95.51 / 745 or 0.12ms per text object. Disabling Record on the profiler increased the fps to 16.7 fps.
Development Build + Profiler (Recording) ~14fps
On that frame 583 text objects were updated which took 41.67 / 583 or 0.07ms per text object. Disabling Record on the profiler increased the fps to 28 fps.
Development Build ~35fps
There are no images here to post since we are not profiling. Again note that a big chunk of the fps is impact by the number of objects were are displaying which is a constant between all 3 build modes tested here.
We could measure the performance overhead of the text processing by using the C# Stopwatch Class where we would measure the elapsed times but we would likely confirm the processing of individual text objects being less than 0.1ms or better.
In terms of the profiler, here is an example with just 1 static text object and 1 dynamic where I compare Development + Profiling (Recording) vs. same with Script Debugging. Notice the reported times are ~2x slower with script debugging.
With Script Debugging
Without Script Debugging
As per the above, we can see the performance overhead resulting from profiling and whether we are profiling with script debugging enabled or not adds additional overhead. The number of objects being tracked likely impacts these results. For instance, in the first example, we had an average of 0.12ms per text object whereas tracking just one was 0.19ms.
The above tests were done using Mono as a backend. Using IL2CPP in release build produced 37.8fps.
Like I said before, the profiler is great to get relative performance but those results are not indicative of the actual performance. I typically use both the profiler and the StopWatch to test specific functions and stuff but also test on the actual target platform / device to check the fps (where applicable) and overall responsiveness / performance while using the app / whatever I am testing.
Note: The # of characters contained in a text object and rich text tags does impact the parsing and layout. The differences between are marginal between character count but would be more significant between 12 character, 100, 1000 or more.
Updating a few text objects every single frame, even on slow devices should not be an issue. Hopefully the above information proves useful.
