rsalmei / alive-progress

A new kind of Progress Bar, with real-time throughput, ETA, and very cool animations!
MIT License
5.45k stars 205 forks source link

Get seconds per iteration in progress bar #184

Open SanderLam opened 2 years ago

SanderLam commented 2 years ago

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!

rsalmei commented 2 years ago

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?

SanderLam commented 2 years ago

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!🙂

rsalmei commented 2 years ago

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! 👍

TheTechRobo commented 2 years ago

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.

rsalmei commented 2 years ago

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?

TheTechRobo commented 2 years ago

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.

rsalmei commented 2 years ago

Ok, I'll think about it, thanks.

Coocys commented 1 year ago

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

rsalmei commented 1 year ago

Thanks, @Coocys. Unfortunately no updates at the moment, I haven't really thought about this yet.