Extreme editor slowdown when using "Collapse Lines" with many different lines.

[MewPurPur]

Godot version

4.0.2

System information

Ubuntu 22.04.1 LTS

Issue description

When "Collapse Lines" in the output dock is enabled, having a lot of different lines in the output makes the editor extremely slow / unusable when trying to add new lines.

This has frozen Godot many times for me when I'm using tool scripts, as every time I get spammed with warnings and errors, the editor quickly becomes unusable, even if my output dock is closed.

Steps to reproduce

Enable the Collapse Lines functionality. Then add this script to a node:

@tool
extends Node

func _ready() -> void:
	for i in 600:  # 600 different lines. You might have to raise this higher to notice the slowdown.
		print(i)

func _process(_delta: float) -> void:
	print(Time.get_ticks_msec() / 1000)  # Should add as many messages per line as the FPS.

You can close the scene, clear the output, and reopen it to restart the test or after adjusting the number of unique lines to be added initially. For me, the editor becomes unusable at around 2000 different lines and pretty much frozen at around 8000 different lines. This problem is completely absent without the Collapse Lines functionality.

Minimal reproduction project

I provided a script

[Zireael07]

Confirming I saw performance issues with Collapse Lines on. They went away when I toggled it off.

(I do a lot of printing to output to debug AI things)

[MewPurPur]

It's because changing the last line causes the whole RichTextLabel to be rebuilt.

[jsjtxietian]

For me, the editor runs at 2-3 fps at around 8000 different lines.

It seems List<struct RichTextLabel::Item *,class DefaultAllocator>::Element::next takes awful long time, with Collapse Lines off this function's performance is ok.

[MewPurPur]

What's wrong is RichTextLabel has to rebuild the whole text, as there's no way to just erase the last line to update the count on it.

A potential workaround is to have two RichTextLabels, one for the last line and another for everything else. But this ugly solution requires some serious "glue" to work with functionalities like filtering.

@bruvzg

[bruvzg]

What's wrong is RichTextLabel has to rebuild the whole text, as there's no way to just erase the last line to update the count on it.

After #77973 it should change only the last line.

[bruvzg]

After #77973 it should change only the last line.

But remove item and remove paragraph code is iterating all subitems List each time, which might be the reason for slowdown as well.

[jsjtxietian]

I tested it with #77973, it is still slow. So based on the vtune profiler provided above, I think this #80857 does solve the hotspot and after apply the patch, performance is ok.