Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get seconds per iteration in progress bar #184

Open
SanderLam opened this issue Aug 24, 2022 · 9 comments
Open

Get seconds per iteration in progress bar #184

SanderLam opened this issue Aug 24, 2022 · 9 comments
Labels
feature request No promises...

Comments

@SanderLam
Copy link

SanderLam commented Aug 24, 2022

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
Copy link
Owner

rsalmei commented Aug 24, 2022

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
Copy link
Author

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
Copy link
Owner

rsalmei commented Aug 26, 2022

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

@rsalmei rsalmei added the feature request No promises... label Aug 26, 2022
@TheTechRobo
Copy link
Contributor

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
Copy link
Owner

rsalmei commented Aug 26, 2022

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
Copy link
Contributor

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
Copy link
Owner

rsalmei commented Aug 26, 2022

Ok, I'll think about it, thanks.

@Coocys
Copy link

Coocys commented Jun 21, 2023

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
Copy link
Owner

rsalmei commented Jun 23, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request No promises...
Projects
None yet
Development

No branches or pull requests

4 participants