-
-
Notifications
You must be signed in to change notification settings - Fork 53
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 initialisation time #189
Comments
Data point: I upgraded my script from timezonefinder 5.2.0 to 6.2.0, and execution time in AWS Lambda went from about 350ms to between 8 and 8.5 seconds. I can't say for sure that it was initialization time at fault, but the problem went away when I downgraded back to 5.2.0. |
That sounds like a lot, but it could be due to low disk read throughput. Have you checked that you are reusing your Timezonefinder instance? (Cf. #176) |
Yeah, I don't know enough about Lambda to know why it's so much worse, but it makes sense that it might be more IO-bound than other environments when doing big reads like this. I am reusing my TimezoneFinder instance (or, more accurately, I'm only using it once). |
At least you could make sure to reuse your instance between consequent lambda calls (e.g. as global variable). Would you be willing to look into the improvement of the initialisation time? |
This is a very low traffic personal project, so using a global variable wouldn't help much (most executions are cold starts), and I don't want to use provisioned concurrency (even though it would only be a few dollars a month, the project currently costs about a penny per month). I'm not a skilled enough library developer to help with this issue, but I'd happily test any new versions. |
currently the initialisation time of a
Timezonefinder
instance is around .7 seconds.This is probably mostly due to reading the polygon index file into memory.
Find ways of reducing the startup time without affecting the query time
The text was updated successfully, but these errors were encountered: