alive-progress
alive-progress copied to clipboard
Get seconds per iteration in progress bar
Hi there!
Love the package and the customisations so far!
I have a process that takes around 2 seconds per iteration. and would like to see something like 2.01s/it
.
The tqdm package automatically switches between iterations per second and seconds per iteration, depending on which one there are more of per second.
For example:
import time
from alive_progress import alive_bar
with alive_bar(3) as bar:
for i in range(3):
time.sleep(2)
bar()
from tqdm import tqdm
for i in tqdm(range(3)):
time.sleep(2)
bar()
Output:
alive-progress:
|█████████████▍ | ▆▄▂ 1/3 [33%] in 3s (0.3/s, eta: 4s)
tqdm:
33%|███████ | 1/3 [00:02<00:04, 2.01s/it]
I've seen the customisation of the stats
option in the alive_bar
, but don't see a way how to change the {rate}
to {1/rate}
stats (bool|str): [True] configures the stats widget (123.4/s, eta: 12s)
↳ send a string with {rate} and {eta} to customize it
Thanks!
Hey @SanderLam, thanks, man.
Yeah, there isn't a way to make this at the moment. But the new version, soon to be released, will feature more scales!
I won't invert the rate as you've said, but I'll make something better: /minute and /hour rate!
So, your example of 2.01s/it
will be displayed as 29.85/min
, how cool is that?
WDYT? Will that fit your expectations?
Hi @rsalmei, thank you for your reply!
I agree that 29.85/m
is better than the current implementation, but I would still vote for having 2.01s/it
.
I'm interested in seeing the time it takes for a single iteration, it's less so about how many I can do in a minute.
But of course it's your package, so your decision! Just the opinion of a user here!🙂
Sure, I understand. Personally, I don't like it that way.
I'm not sure whether this use-case warrants support in alive-progress
itself, since the majority of the time one should be monitoring processes in the ms or µs or even ns ranges... This means k/s or even M/s.
I'll think about it better, and will let you know! 👍
I'm not sure whether this use-case warrants support in alive-progress itself, since the majority of the time one should be monitoring processes in the ms or µs or even ns ranges... This means k/s or even M/s.
Really? I use mine for long-running, slow iterations, because of alive-progress's amazingness. You don't IMO only need to use a progress bar with short iterations.
Nice @TheTechRobo, thanks for your input!
And for these long-running processes of yours, would you rather see 3.5/hour
or 17.14min/it
?
I don't really mind either way, but in some cases it might be better to show the per-iteration speed. It's easier to interpret "each one takes about 17 minutes" than "3.5 ones per hour" IMO. I think it should be configurable.
Ok, I'll think about it, thanks.
I don't really mind either way, but in some cases it might be better to show the per-iteration speed. It's easier to interpret "each one takes about 17 minutes" than "3.5 ones per hour" IMO. I think it should be configurable.
I have the same opinion. In my case the the iterations take about 10 minutes too.
Is there any update on some sort of implementation? That would be lovely. But its an amazing library as it is already, nice work :) @rsalmei
Thanks, @Coocys. Unfortunately no updates at the moment, I haven't really thought about this yet.