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

Improve Startup Response Time #182

Open
Erotemic opened this issue Feb 8, 2025 · 1 comment
Open

Improve Startup Response Time #182

Erotemic opened this issue Feb 8, 2025 · 1 comment

Comments

@Erotemic
Copy link
Member

Erotemic commented Feb 8, 2025

Currently the startup time of the application is 5 seconds on a powerful machine, which feels very sluggish. This is due to the fact that most imports are at the top of each file, so things like torch, timm, numpy, scipy, and other heavyweight python modules are all loaded before the user gets any visual feedback.

This could be improved by using local imports and delaying the initialization of things like models until they are needed. The idea is that on program startup we don't need to have a model loaded until the user actually wants to compute embeddings, and even then, the loading of that model could be done asynchronously so the user can interact with the dataset while the model is loading in the background. Unfortunately, this does make using type annotations a bit tricker, but it can be done with things like typing.TYPE_CHECKING.

Overall this is a minor issue, but I wanted to raise it now given that if there was a desire to address it it would take a non-trivial amount of code restructuring.

@PaulHax
Copy link
Collaborator

PaulHax commented Feb 12, 2025

Startup time is a problem. Thanks for the guidance.

Another wrinkle: we compute embeddings automatily at the start and the GUI does not load untill done. This can take a while, ~70 seconds, with 500 shitspotter sized images.

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

No branches or pull requests

2 participants