Performance: Reduce heap allocations and cloning strings

[parasyte]

I noticed that most widgets that render text also own a copy of the String. This was a bit alarming due to the nature of immediate-mode GUI designs. For instance creating a Label with a &'static str has no reason to clone and take ownership of this string, given the Label only lives long enough to create a few paint operations. The deeper I dug, the more I saw this pattern used. The Font structs also take ownership of a String and so forth.

#302 really lead me further down this rabbit hole. And though I kind of like the added ergonomics of creating a Label et al. from a number or Box<dyn Error>, I'm still concerned about the cost of cloning strings.

To begin quantifying that cost, I created a copy-pasta duplicate of the Label struct and cleverly named it CowLabel<'a>, owning a Cow<'a, str> instead of String. The constructor avoids cloning quite simply:

pub fn new(text: impl Into<Cow<'a, str>>) -> Self

... along with the usual From<T> impls and a convenience method on Ui. Then some new benchmarks:

c.bench_function("cow-label &str", |b| {
    b.iter(|| {
        ui.cow_label("the quick brown fox jumps over the lazy dog");
    })
});
c.bench_function("cow-label format!", |b| {
    b.iter(|| {
        ui.cow_label("the quick brown fox jumps over the lazy dog".to_owned());
    })
});

Here are my results in comparison to Label:

label &str              time:   [1.2327 us 1.3125 us 1.4843 us]
                        change: [-74.188% +0.1233% +211.86%] (p = 0.99 > 0.05)
                        No change in performance detected.
Found 6 outliers among 100 measurements (6.00%)
  2 (2.00%) high mild
  4 (4.00%) high severe

label format!           time:   [725.95 ns 863.11 ns 1.0752 us]
                        change: [-20.183% -2.3797% +19.466%] (p = 0.82 > 0.05)
                        No change in performance detected.
Found 9 outliers among 100 measurements (9.00%)
  2 (2.00%) high mild
  7 (7.00%) high severe

cow-label &str          time:   [638.74 ns 860.07 ns 1.2059 us]
                        change: [-28.983% +2.1126% +46.242%] (p = 0.91 > 0.05)
                        No change in performance detected.
Found 9 outliers among 100 measurements (9.00%)
  3 (3.00%) high mild
  6 (6.00%) high severe

cow-label format!       time:   [688.00 ns 690.81 ns 693.66 ns]
                        change: [-5.4290% -4.5654% -3.7306%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 4 outliers among 100 measurements (4.00%)
  3 (3.00%) high mild
  1 (1.00%) high severe

This is far from scientific and of course it doesn't go any further on optimizations or attempt to remove other clones for Galley or Font or any of these underlying layers. But it does show a modest improvement for both borrowed and owned strings.

Thoughts and opinions?

[emilk]

Since a recent refactor of how and when text is laid out, it should be possible to remove the need for Galley to take ownership of a String (with a bit more work). But, i don't consider it a high priority. As you noticed, allocations aren't that expensive. Even with a hundred labels, the above gains only add up to tens of microseconds. With something like jemalloc I'm sure it would be even less. If you want egui to run faster, there are much lower hanging fruit!

[parasyte]

I agree this doesn't seem like something worth optimizing for most users. My use case will be on the more extreme side; a hex editor, disassembler, and code editor. Each with contextual and syntax highlighting. Something like ImHex, if you are interested in a visual illustration.

A reasonably sized hex editor window can draw 2,000 small strings (or more). If we assume 1μs for each string and ignore potential application-side optimizations, that's a quarter of the frame budget at 120 Hz. And we still haven't accounted for anything except creating labels. My only point is that a few microseconds can add up quickly.

[ShirenY]

I noticed this today. As me want to use this framework to implement some dev tools, each label with user data need to be cloned for everyframe concerns me.