test(block): add benchmarks

[Valentin271]

Description

I added benchmarks to the block widget to uncover eventual performance issues.
I tried to cover common (creation, render) or expensive (inner area) calculations. I also ran the benchmark with three different common buffer sizes.
From what I can see it doesn't seem to have any bottleneck here.

What is covered by the benches :

• Block creation
• Render with different parameters (empty, titles, borders, padding)
• Computing inner area

Details

• This PR adds benchmarks only for block. I think it's a better idea to split the work on benchmarks to add them incrementally.

• I'm not sure the black_box is really necessary for the block creation bench. Otherwise the compiler advises to put the new function reference as parameter (see below). I'm afraid this is less legible and might not work as expected.

group.bench_function("new", |b| b.iter(Block::new));

• Lastly, I have a small concern about my benches reports not looking the same as the paragraph ones :
  
  I based myself off of this bench (the paragraph one), so I'm not sure this is the expected behavior (works in the terminal and results are correct once clicked on though).

---

This PR relates to #137.

Thank you for your review and your work.

[codecov]

Codecov Report

Merging #368 (2887861) into main (e82521e) will not change coverage.
Report is 3 commits behind head on main.
The diff coverage is n/a.

❗ Current head 2887861 differs from pull request most recent head a61bf39. Consider uploading reports for the commit a61bf39 to get more accurate results

@@           Coverage Diff           @@
##             main     #368   +/-   ##
=======================================
  Coverage   84.99%   84.99%           
=======================================
  Files          40       40           
  Lines        8686     8686           
=======================================
  Hits         7383     7383           
  Misses       1303     1303           

[joshka]

I think you probably need to have a numeric value to get the output like the paragraph (could use Rect::area() for this value)

[joshka]

LGTM. I'd be surprised if this really ever has significant perf issues.

To keep the benchmark times down, it's worth consolidating some of the benches. E.g. forget about the bare new() bench. This was only necessary in the paragraph benches as we're testing some fairly large strings (~200*65535 chars) to understand the limits of scrolling and wrapping.

I suspect (without running these) that the render times are likely fairly similar (or the absolute value is small enough that the relative difference is irrelevant). In which case, it's probably sufficient to bench an empty block, and one with all the features (titles, borders, styles, padding etc.)

Can you paste some of the output metrics into the PR? It doesn't hurt to have them recorded for posterity later.

[Valentin271]

I think you probably need to have a numeric value to get the output like the paragraph (could use Rect::area() for this value)

Yes, you're right. I used area as suggested. Too bad criterion cannot use text as a table entry :/

LGTM. I'd be surprised if this really ever has significant perf issues.

Same here, just thought I'd benchmark the main building blocks starting with the easiest for me.

I suspect (without running these) that the render times are likely fairly similar (or the absolute value is small enough that the relative difference is irrelevant). In which case, it's probably sufficient to bench an empty block, and one with all the features (titles, borders, styles, padding etc.)

After modifying the benchmark according to your review and looking more in depth, render times are similar : only 10 to 50 µs between empty and with all features for the biggest area (depending on the run, on my machine of course).

Can you paste some of the output metrics into the PR? It doesn't hurt to have them recorded for posterity later.

Sure, here are some comparisons I found interesting (keep in mind this was recorded on my machine, you might not get the same results) :

Figure 1: Time to render all features relative to the buffer area

Figure 2: Time to render an empty block relative to the buffer area

Figure 3: Time to render an empty block and one with all features on a maxed ou area

Figure 4: Time to render an empty block and one with all features on a common area (200x50)

The last two graphs are interesting because we can see a difference when rendering all features on figure 3 (which is to be expected) but when used in a common context there's actually no visible difference (figure 4).

---

• I removed the smallest area (20x10) because it was always about 1µs, I don't those times are really of any use
• I also removed the inner computation as it was taking 5 ns constantly

[joshka]

Looks good - I think Figure 4 is the one that matters the most here. And it's fast enough.
Thanks for doing this - it's another good base test to add to.