-
Notifications
You must be signed in to change notification settings - Fork 633
Slow library import time #935
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
Comments
One thing that could be done is to load the logger modules on demand similar to how we only load interfaces when needed. But that could affect the official API. |
Hmm that is annoyingly slow but I'm not sure what to do about it. Do you mind uploading the import profile? If a blank user display is the main concern is there anything preventing you from initializing it first, showing a splash screen/progress screen etc before importing can? |
It seems pkg_resources takes 1,5 s to load alone. You could comment out imports that you don't need to make it load faster. But I don't think we can do it without changing the API completely. |
So this is all very new to me, I don't have much experience with python (or any interpreted languages really). Happy to profile the runtime: I tried to run cProfiler but it hang mid execution - I'm not sure why either because of threading or some other issue. I will have another go later. Definitely willing to try commenting out some dependencies if you have any recommendations on where to start. This was an interesting read, but didn't really give me an avenue to cut out anything (particularly pkg_resources). Edit: Buildroot (by default) installs all python libs in a compiled *.pyc format - would that have any material impact? |
Any suggestions on what I can try to selectively load modules? Happy to do some testing if there is some direction available. Thank you. |
Yes, it seems to be the case that we can't do much here. Sorry. |
I'm closing this for now since I don't see what we should change here. |
Maybe we could use importlib instead. It is for 3.8 and newer only so a fallback to setuptools would probably be needed. |
I think this is completely covered by #1234 |
I have been attempting to use python-can on an embedded buildroot system, which essentially will be a CAN based display.
Hardware is relatively low level, single ARM Cortex-A7 1.2GHz, 64mb ram, SPI can interface, SD card based storage/boot media.
I had done some function tests with python-can originally and it had worked as intended, but now I am getting to optimisations and I am stumped. Now I have introduced python-can into my runtime, library import -- "import can" is taking a huge block of time which is interfering with the user experience.
As library imports are blocking (as far as I know) its causing a blank screen for the duration of the load time until the display library can make a call and refresh the display.
My typical load times for the can library are in the 2800ms > 3000ms range, which is forever compared to the rest of the process, some benchmarks for reference:
I'm using the bare minimum of the library:
No logger, no asnycio, no other interfaces or parts of the API.
Is this load time normal?
or is there an issue which is slowing down the use of the library?
what avenues exist to speed up this process? (selective loading?)
some data from the target hardware:
The text was updated successfully, but these errors were encountered: