gradio icon indicating copy to clipboard operation
gradio copied to clipboard

Published 20 hours ago • verified publisher icon gradio-app

Add a default ETA for each function in the app

Open jfrery opened this issue 1 year ago • 3 comments

  • [x] I have searched to see if a similar issue already exists.

First thanks a lot for the great repo! I could never think of creating an ML interface that quick. I was quite impressed.

I am looking to do something very simple but was unable to find the relevant doc/issue.

I would like to set a default processing time for the functions. Currently, it seems that gradio tries takes the average of the past few run to have an ETA. But since the app runs on a specific machine we already know what the default running time should be for a specific function and that would be relevant for the users to know.

I feel that I might miss the point here or maybe I was just unable to find the right documentation.

Thanks!

jfrery avatar Sep 07 '22 15:09 jfrery

Hi @jfrery this isn't currently supported, but having a default initial ETA would be a nice thing to add. We can consider this in the future or are open to reviewing any PRs if you'd like to contribute this feature!

The place to start would be to add a parameter default_eta to any event here: https://github.com/gradio-app/gradio/blob/a69fd1de132a218003bfc20e6850f9793c44f635/gradio/blocks.py#L104 and then use that as the initial value of the ETA in the queue

abidlabs avatar Sep 07 '22 20:09 abidlabs

Thanks for the answer. I will see if I can implement this feature with your advice!

jfrery avatar Sep 08 '22 05:09 jfrery

FYI @jfrery, just realized that we might need to first implement #2216 before this would make sense (at least in settings where you have multiple functions running.)

abidlabs avatar Sep 09 '22 00:09 abidlabs

Hi @jfrery thanks again for creating this issue. We discussed and it seems like having separate queues for separate events would lead to unnecessary complexity in the app so we have closed #2216.

So in order to support this, we'd have to store event-specific information in the queue which we don't currently do, and this doesn't feature seem like it would solve a significant pain point (for most users, the ETA estimation is a "nice-to-have"), so I'm inclined towards closing this issue. Let me know your thoughts and if I'm missing anything.

abidlabs avatar Sep 28 '22 00:09 abidlabs

Hi @abidlabs,

Understood. Yes it makes sense.

Closing the issue.

Thanks again for the awesome lib!

jfrery avatar Sep 28 '22 04:09 jfrery