Shorten rust-timer's GitHub comments even more

[miikkas]

This PR continues the optimization I started in #2151. (Relates to #2149.)

Mock comparison on PC, before and after

Mock comparison on mobile, before and after

[miikkas]

I have some further ideas on how to continue this, like

• moving some of the explanation and advice to https://perf.rust-lang.org/help.html and linking that page directly from rust-timer's GitHub comments, and
• hacking on the tables summarizing the perf run results (possibly with abbreviations with added explanation on the help page linked above etc.)

Would such changes be welcome?

[nnethercote]

Needs a rustfmt run.

The word changes seem fine, it's a little shorter without losing any information.

As for further changes, the table seems the best place. If the labels in the left hand column could be made to fit on a single line, that would save some vertical space. Other than that I would be careful about removing information... we need a balance between enough explanation for newcomers vs. what works for experts. It doesn't feel like we can drastically shrink it.

[miikkas]

Thanks for the review! I have amended the commit with rustfmt'd code.

As for further changes, the table seems the best place. If the labels in the left hand column could be made to fit on a single line, that would save some vertical space.

Agreed. I will try working on this, and will open a separate PR if I succeed in saving space here. :)

[Kobzol]

I think we're running into diminishing returns here, and I'm not sure if it's worth micro-optimizing further. At the end of the day it's a wall of text that new people might read, but people who see it every day will just ignore it, because they know what it says.

I like the removal of "the text below" though, that's nice compression 😆

[miikkas]

At the end of the day it's a wall of text that new people might read, but people who see it every day will just ignore it, because they know what it says.

This is the dilemma. How to best serve both seasoned and new contributors, each with different priorities.

The compression here and in the previous PR improve the SNR, I think, which benefits both user groups. But I agree we're probably nearing the limits within the current overall design.

[nnethercote]

Worth merging, IMO, but I agree there is not much more juice to be squeezed here.