feature: rough progress during target file read

[roycewilliams]

When reading a file directly (not reading from stdin), the number of bytes read in, vs the total size as read from disk, could be used to show a rough progress indicator. As long as this doesn't materially slow down the read, this could be useful.

[Waffle2]

What is the longest time, when not reading from stdin, does rling take to read your largest file?

…

On Aug 29, 2022, at 11:34 AM, Royce Williams ***@***.***> wrote: When reading a file directly (not reading from stdin), the number of bytes read in, vs the total size as read from disk, could be used to show a rough progress indicator. As long as this doesn't materially slow down the read, this could be useful. — Reply to this email directly, view it on GitHub <#38>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGQE5I555LX6JQUD3WNQBTV3T7DNANCNFSM576ZGE2A>. You are receiving this because you are subscribed to this thread.

[roycewilliams]

High-end case (just for me personally) is ~64GB from spinning rust:

Reading "[filename]"...64798075953 bytes total in 215.7301 seconds

[Waffle2]

So, about 300 Mbytes/sec. Is it really worth it to add a progress bar? The vast majority of files will be handled effectively “instantly” - more time will be spent in the other phases of the program, do have progress (of a kind)… Am I wrong here? I’ve been using rling pretty extensively lately (mostly in pipelines), so maybe I’m biased.

…

On Aug 29, 2022, at 12:52 PM, Royce Williams ***@***.***> wrote: 64798075953

[roycewilliams]

I wasn't thinking progress bar so much as a simple % completed as used elsewhere in rling (that's often also only shown briefly when shown in other parts of rling - but it's handy to see when it's not brief. :D)

Sometimes it's most useful when the user has made an error - so the percent complete is going up much more slowly than expected, which the user can immediately notice and take action on.