-
-
Notifications
You must be signed in to change notification settings - Fork 180
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
load faster... #407
Comments
It looks like the imports are taking a while. Will look |
A minimal example. Even something simple like this takes ~5 secs (M1 MBP Pro Max) to get to printing "hello":
@nilspalumbo do you think this may be due to the various top level imports? Or maybe some imports are running code? |
Hmm that could be possible when running |
if I rename class LazyModuleLoader:
def __init__(self, module_name):
self.module_name = module_name
self.module = None
def __getattr__(self, name):
if self.module is None:
self.module = __import__(self.module_name, fromlist=[name])
return getattr(self.module, name)
module1 = LazyModuleLoader('blah.module1')
module2 = LazyModuleLoader('blah.module2')
# Repeat for other modules as necessary
# Then, to allow for 'import blah as bl' and 'bl.module1', etc.
__all__ = ['module1', 'module2'] # List all module names here |
I think we should do that; the loss of transparency isn't too bad. Hopefully mypy tolerates it; this might cause problems with static analysis. If it doesn't, I'll update things. |
Turns out even if I add lazy loads in every |
:-( looks like one has to live with it as part of program. don't suprise me when guess refactoring the package might be one way provided that's on the roadmap |
Hmm perhaps we if we replace the imports with a single |
You mean do this at the top and within the code in base.py we access everything using “lr.” ? Yes that should work |
Yeah, that's what I was thinking. We may want to keep some additional imports to keep the code clean though; importing sub-packages rather than individual modules would help with that, since lazy loading would still apply in that case (and the init files are very light). |
ran this dependency graph:
|
for kicks tried langchain
|
Short answer is No. We have to put some time into deciding what we want to consider as "core" langroid, for a "batteries-included" experience. We can certainly mark a bunch of these as "extra" dependencies in |
atleast knocking off |
Wow, surprising to hear that, thanks much for digging into this! We'll think about the right way to set this up. |
So... large number of dependencies and slow imports may be orthogonal issues. Reducing deps is good but won't speed up the imports, which is simply due to the large number of imports in For dependencies, I'm finding that |
what's the |
It's for parsing pdf docs, but I just made a new release that eliminates |
did an update and this is what i get for sample code at top
|
yes I don't expect this to improve the script startup time. That is still an issue due to the large imports in |
i quickly looked at it but could'nt discern which import is the killer, other than |
takes a long time to load (mbp 2020 16gb ram i5) making iterations slower... can you post some tips to load faster?
The text was updated successfully, but these errors were encountered: