RichTextLabel performance observations

[gokiburikin]

Posting my findings here so I can stop opening and editing issues that I'm not sure are even bugs. No idea if this is useful information, but I have seen a few "text is very laggy" issues opened since 4.0 launched.

Rendering BBCode with no line breaks

Significantly slower in 4.X than 3.5. This seems to be somewhat expected behaviour based on godotengine/godot#79599 (comment) but the disparity is very large.

Of note, it seems like all the time is spent in RichTextLabel::_get_item_at_pos if I'm reading the profiler correctly. (VerySleepy 0.9.1 profiling 4.0.3 with debugging symbols)

Godot_v4.2-dev3_win64_2023-08-15_23-08-00.mp4

x264.4.1_text_rendering.mp4

x264.3.5_text_rendering.mp4

Clearing and Setting BBCode text every frame

Significantly slower in 4.X than 3.5. This is not an efficient way to use RTLs but it is a very big performance drop compared to what it was before. Of course, RTLs are also much more functional now so maybe this is a required tradeoff.

Here are the profiler results for this MRP. (VerySleepy 0.9.1 profiling 4.0.3 with debugging symbols, for 10 seconds total)

External module / thread waiting stuff

Including external modules

Lots of time spent starting up Threads maybe? I can't really understand these results I think this is just waiting for thread joins

I noticed ntdll was filtered out so here's a completely unfiltered (afaik) list

Of note, the call to Clear itself seems to take a while when there are a lot of tags in the RTL already.

x264.2023-08-16.02-06-43.mp4

Threading

I couldn't get what looked like any useful profiler information for where clearing and setting is spending its time because most of the time was spent doing stuff with threads.

I didn't notice any threading stuff when it came to rendering BBCode with no line breaks.

Enabling threading to mitigate these stalls isn't an option if you're changing text every frame due to godotengine/godot#80613.

[Calinou]

I couldn't get any useful profiler information for where clearing and setting is spending its time because the only calls in the profiler were waits for threads.

You can use a C++ profiler in a debug build of the engine.

[gokiburikin]

I did try in the same way I got the information for BBCode with no line breaks, but it looks so much different I couldn't tell if it was relevant. I've added the results now.

[gokiburikin]

Edit: This apparently just offloads the work to be done, probably defers it so it isn't picked up by this timing method. RTL nodes really do just seem to be this slow.

Just a little follow up as I've stumbled onto a bit more information about RTL performance.

Enabling Fit Content on an RTL causes it to take almost 500% longer to be added to the scene than if it's disabled. MRP results in ~560usec to add as a child with some realistic use case BBCode but ~3000usec if Fit Content is enabled.

My use case is stacking RTLs vertically interspersed with other Control nodes inside of a ScrollContainer (for complex tooltips) which requires Fit Content to work. I dynamically build the tooltip by calling functions like add_label.

What I will do is find a way to never actually remove RTLs from the tooltip and simply hide / move them to where they need to be to avoid this performance issue.

For what it's worth setting visible_ratio or changing the text to something that recalculates the minimum size does NOT perform poorly, only Fit Content being enabled when adding an RTL to the tree seems to.

Heads up: rapid flickering

rtl_add_child_mrp.mp4