-
-
Notifications
You must be signed in to change notification settings - Fork 543
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
Enable lazy loading of submodules #3490
Comments
Hey can I look into it? |
Thanks for replying. I will be looking at other issues in the meantime. |
See also: https://docs.python.org/3/library/importlib.html#implementing-lazy-imports; a rather crude, bare-bones implementation for delaying imports |
I can look into this now. Keeping in mind that it is not a beginner level issue and @prady0t is occupied with other one. |
Hi @arjxn-py @agriyakhetarpal If you're not working on this issue, May I go ahead and try to solve this? Also can you guide me? |
Hey @AbhishekChaudharii, thanks for showing your interest on this but I am currently on it and going to open up a PR in a couple of days. Feel free to look into other issues 🙂 |
Sure no problem :) |
@arjxn-py Can we close this now? |
I would say we should keep it open (other, large packages are able to make it work – maybe we can too), but yes, it is @arjxn-py's call after all |
I thought the consensus was that it was not a major bottleneck so the work/code required to do it was bigger than the problem |
Right, maybe let's not close it because it's still within scope but lower down the priority for now – I'll change the labels. |
We can always open new tickets when problems recur, no need to keep this open |
But this is a recurring problem, isn't it? I just tested this in a fresh notebook/kernel without |
I just noticed that https://github.com/scientific-python/lazy_loader is now being recommended for Python versions 3.11 and later, and that too, with very specific minimum patch versions to avoid races, say 3.11.9, for example. Python 3.11 being the lowest version for us will be quite many years away at the time of writing (at least four). It sucks that I would have liked to have seen this done for PyBaMM but I don't think we have a viable choice at this time, I think we can close this and re-open later (or open a new issue, whichever way works). A better and more reliable way would be to profile PyBaMM's import and see which of the bigger modules are causing the bottleneck, and if needed then implement minor breaking changes or lazy loading at the functionality level manually at the time of use of a function, so that we aren't importing a lot of those functions when one runs |
Enabling lazy loading of submodules should potentially make PyBaMM import faster.
See also: https://scientific-python.org/specs/spec-0001/
Originally posted by @agriyakhetarpal in #3475 (comment)
The text was updated successfully, but these errors were encountered: