Created attachment 132952 [details]
Observed call graph (cycle detection on)

Hi,

How to observe: Open kate, and make a new text document consisting of 2^13 lines of "test" (e.g., "test", RETURN, CTRL-A, CTRL-C, DOWN, CTRL-V, repeat 11 more times...). Paste that into new kmail composer window. Edit in composer, inserting lines randomly and adding whatever gibberish you like - things operate reasonably okay.

Now make 2^13 lines of "> test" (e.g., Replace All "test" with "> test"), paste it in, and try editing that. After a few seconds for me, the UI then freezes for a good 20 seconds. It will seem to come back, then freeze again after a few more seconds (it doesn't seem consistent). I feel like my Ryzen 3700X should be able to treat a few thousand lines of text with ease, but here we are.

I've had message chains between colleagues that end up like this - thousands of lines of quotes due to multiple rounds of HTML/text conversion and line splitting. Using one such example I had encountered, I tried doing a callgrind analysis for the time the composer was preparing to display the message. From that, I'm seeing two calls to QSyntaxHighlighter::rehighlight() are apparently turning into a few thousand calls to QSyntaxHighlighterPrivate::reformat, and in turn about 22 million calls to QTextDocumentLayoutPrivate::layoutBlock(). That seems like a lot, but I confess I'm not certain how to interpret the results (or the implication of "Cycle Detection" in KCachegrind), so I'll attach some call graph images in hopes it's useful.

For what it's worth, I have not found this effect in kate, even while the text is being syntax highlighted.


SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.14.2