Avoid cloning text in TextEdit for Arc<str> text buffers

[afishhh]

A large chunk of time spent each frame on large immutable TextEdits is cloning the text string repeatedly:

This PR attempts to switch surrounding code to Arc<str> and adds TextBuffer::clone_to_arc + impl TextBuffer for Arc<str> which allow skipping most of the string copying work for buffers that are themselves Arcs.

These changes (and modifying the app to pass Arc<str>) make the profile look like this:

¹

Clearly better and decreases the frame times in this test app by ~10ms.

However there is one elephant in the room (the remaining to_owned) that requires more invasive changes to handle: LayoutJob. This elephant is actually very significant: I am able to achieve acceptable performance (in my real-world app that I'm trying to speed up) with a 1MB XML string if I apply a hacky solution to avoid cloning the string on LayoutJob creation.

Here's what that looks like on the benchmark (#7649 + this + hacky LayoutJob fix):

¹²

This does require changing LayoutJob though and I'm not exactly sure what to do here which is why this is a draft. Should I just make LayoutJob itself immutable and add a builder type for it? If so what should the builder type's API look like? There's a few possibilities that come to mind but not sure I particularly like any of them.

• I have followed the instructions in the PR template

Footnotes

1. Ignore the sample count, these profiles were run for completely arbitrary amounts of time. ↩ ↩²

2. Also suggests that the next optimization opportunity is in skipping undo handling for immutable buffers, along with PaintStats related stuff which is not visible here but constitutes a large percentage of runtime. ↩

[github-actions]

Preview available at https://egui-pr-preview.github.io/pr/7673-textedit-less-cloning
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

View snapshot changes at kitdiff

[afishhh]

Actually for my use case it seems sufficient to make the layout_job layout entry point accept an Arc<LayoutJob>. That's enough for displaying large amounts of immutable non-line-wrapped text. It's not perfect but it works and doesn't require changing how LayoutJob itself works.

[afishhh]

This is slightly unfortunate and could be avoided by threading a separate max_width throughout layout but that sounds like a lot of work while when working with a lot of text you probably don't necessarily need line wrapping anyway.

[emilk]

Overall looks good, but I would love it if you added some benchmarks to crates/egui/benches and showed us the before/after numbers of that. Otherwise this may regress again.

[emilk]

I suggest we do this in this PR, or it feels a bit half-finished

[afishhh]

I do agree but this goes straight into a LayoutJob and I'm not sure how exactly to handle Arcifying that.

Should I just split out a builder type and make LayoutJob itself immutable?