Open roycewilliams opened 2 years ago
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 https://github.com/Cynosureprime/rling/issues/38, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGQE5I555LX6JQUD3WNQBTV3T7DNANCNFSM576ZGE2A. You are receiving this because you are subscribed to this thread.
High-end case (just for me personally) is ~64GB from spinning rust:
Reading "[filename]"...64798075953 bytes total in 215.7301 seconds
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
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.
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.