-
-
Notifications
You must be signed in to change notification settings - Fork 160
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 import times #403
Comments
You can probably speed up that by specifying a particular backend using the configuration file or The other offender you named, |
I tried setting function call times
|
Ok if I set PYTHON_KEYRING_BACKEND and make the following change it speeds things up by about a second:
|
I think ideally I would want keyring to only load the backend it was going to use, as opposed to loading every backend and only then choosing which to use. |
Can you please make a pull request with that change? |
If a keyring is set in configuration or environment variables, use that one and don't load all available keyrings. Partially addresses jaraco#403.
I made a pull request for that change. The import time is still poor if the PYTHON_KEYRING_BACKEND environment variable is not set, which it will not be for most users of my project. Maybe there could be a way to see the priority of a keyring without having to fully initialize it, with lazy loading or something similar? |
It seems like there is a great deal of runtime reflection currently ( |
Ah I think I see the issue - the classes themselves are checking at runtime to see if they are viable |
We support also third-party backends, not only our own ones. |
The latest keyring (19.3) uses |
With a cold cache, 19.3 takes 3883241 microseconds (best two out of three, other times were 4051557 and 4525618), or about 4 seconds. I used With a warm cache, 19.3 takes 100266 (best 2/3, others were 104365 104852) microseconds to start up. I used With a cold cache, 19.2 takes 3310792 (best 2/3, others were 4067318 and 3724380) to import. With a warm cache, 19.2 takes 65521 (best 2/3, others were 71301 and 66863) to import. So in short there was a minor slowdown from 19.2 to 19.3. |
I want to emphasize though that most of the slowdown is coming from importing the backends, not from the normal startup time for a pip package. |
I've noticed that import ttime improved significantly if all backends are viable (or at least SecretService is there). With only kwallet i had like 10-12s 'import' time. (keyring==18.0.1) in core.py the line keyrings = filter(limit, backend.get_all_keyring()) adding a function to save the config files based on the: keyrings = filter(limit, backend.get_all_keyring()) call would be a nice addition |
Startup times on macOS are about 170ms. I'd expect something similar on Windows. Part of the challenge on Linux is all of the service interop with long or indefinite timeouts. I welcome efforts to improve that performance and also welcome lazy evaluation. I do agree it would be best if keyring didn't have behavior on import. |
Importing keyring takes more than 2 seconds with a cold cache on my machine, which is more than half the startup time of my CLI app (I have a very slow hard disk). Would it be possible to improve the start time a little?
The main offenders are
secretstorage
andkeyring.core
, which makes up more than half the time on its own. Timing info is generated withpython -X importtime -c 'import keyring'
. I ensured a cold cache withecho 3 | sudo tee /proc/sys/vm/drop_caches
as per http://stackoverflow.com/questions/9551838/ddg#9551853, it's probably different on non-linux systems.Timing info
The text was updated successfully, but these errors were encountered: