-
Notifications
You must be signed in to change notification settings - Fork 395
FewestModules OOMs with dynamic dependencies #4985
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
@steinybot splitting this out, because this is almost certainly an algorithmic issue in the FewestModules analyzer (this is what happens if you build an algorithm yourself 🤷 ). For starters, I would expect this to also happen in fastOpt (provided you run with FewestModules). Could you check that? |
Also, could you give me a rough ballpark of how many |
Yep it happens with
There looks to be about 128 uses of |
One thing that looked a little odd is how For example here is the result of
|
Ah I think this is an issue because it is doing a depth first traversal of the dependencies but it is searching for the shortest paths. In our case we have a sealed trait |
I'm getting OOME's with 10G of memory for
fullLinkJS
andFewestModules
. About 98% of it is fromorg.scalajs.linker.frontend.modulesplitter.Tagger#allPaths
.Every entry that I looked at in here has a long hierarchy of dynamic dependencies with a lot of duplication although some differences. It seems like the way that this graph is constructed is not very memory efficient. For example:
I was trying to fix our module splits by adding more dynamic imports. We have routes which import entry points and then those entry points import the views. It didn't OOM until I added the imports in the entry points (but the splits weren't right). It still doesn't look like I have the imports right (looks like the route is pulling in the layouts) but it shouldn't OOM.
In case it helps:
Originally posted by @steinybot in #4906 (comment)
The text was updated successfully, but these errors were encountered: