fix constant updating of progressbar

[untitaker]

In other issues I've already lamented how slow lychee is when used
without -n. This fixes an issue where without -n, lychee would take
1 minute instead of 4 seconds to check sentry-docs.

[mre]

Yeah indicatif is really challenged with many concurrent requests.
Will this change cause the progress bar to "stutter" or is it fine?

[lebensterben]

Actually running faster is more important than progress bar looks faster....

[untitaker]

I assumed so and was happy to make the tradeoff but I can't spot a difference.

…

On Fri, Feb 4, 2022, at 15:38, Matthias wrote: Yeah indicatif is really challenged with many concurrent requests. Will this change cause the progress bar to "stutter" or is it fine? — Reply to this email directly, view it on GitHub <#488 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMPRPRWGV5DUWN2VW2IG3UZPQHDANCNFSM5NR4DIKA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[untitaker]

I might have forgotten to recompile. But I think you should try yiurself and decide if it feels right. We can also set draw-rate to 100 and probably get the same effect

[mre]

I will benchmark it tonight. Sounds promising! 😄

[lebensterben]

"cargo" itself updates per 100/500 ticks:

• Initially it wait for 500 ms to prevent short lived operation from flickering.
• When a progress bar actually starts moving, it updates once per 100 ms.

[untitaker]

i just checked again, and realized I used the wrong units for set_draw_rate, i.e. i was limiting the updates to 500/second, so once every 2ms. I pasted in @lebensterben's values and I still can't see a significant difference, visually. Maybe I just have no taste. Now lychee should roughly do the same as cargo.

[mre]

Thanks for adding the comments.
Reading through the documentation, I wonder if we even need enable_steady_tick:

Spawns a background thread to tick the progress bar
When this is enabled a background thread will regularly tick the progress bar in the given interval (in milliseconds). This is useful to advance progress bars that are very slow by themselves.

Our progress bar should not be slow. 😆
Did you try to remove that entirely?
A tick automatically happens on every change to a progress bar.
The only situation where this might not be enough is when we're waiting for the last few requests that we'd have to retry. 🤔 Overall it might not be worth the extra testing, but I wanted to put this out there at least.

[untitaker]

A tick automatically happens on every change to a progress bar.

Well not anymore now, that's the point, right? But yeah it's probably unlikely that lychee gets into a situation where steady tick does something... unless it is literally stuck on a single request taking forever.

[mre]

unless it is literally stuck on a single request taking forever.

yeah, let's keep the steady tick. Users might be confused if the tool is "frozen" when it gets stuck on a slow website.

[untitaker]

Seems like indicatif has their performance story mostly sorted out on master: console-rs/indicatif#363

[mre]

Benchmarks from my machine:
master: 12.722 seconds
this branch: 1.374 seconds
Nice improvement indeed. 🚀

[mre]

Thanks @untitaker. 😊