I have an idea to fix this but I need a repo where the build is moderately long (from 10s to 5min) because of this plugin. Could someone provide it?

I don't have one, I'm sorry... Investigation on this was mostly from exchanges with @pleerock over at angular/angular-cli#5618 (he's the one that experiences the problem).

I'm guessing it's because of the chunk quantity but to be honest it might not be.

Please try webpack 4. There is a 80% chance that this has been fixed.

@filipesilva is it possible to use angular cli with webpack 4? (maybe with night builds) then I can check it?

I've opened a PR to attempt to fix this. Another maybe-solution could be to replace the Queue by a UniqueQueue to avoid processing the same chunk multiple times.

@pleerock I have angular/angular-cli#8611 but it probably will break on stuff. If you want to try it you'll have to link it to your project like detailed in https://github.com/angular/angular-cli#development-hints-for-working-on-angular-cli.

This might be a bit involved though. Happy to get on that screenshare you mentioned to help you set it up. Might have to disable stuff that uses plugins that don't yet work with webpack 4 as well.

@filipesilva I have new reports with your branch and webpack 4. First 10+ minutes of RemoveParentModulesPlugin execution without max_old_space_size being set:

webpack4_no_high_memory.cpuprofile.zip

First 10+ minutes of RemoveParentModulesPlugin execution with max_old_space_size being set:

webpack4_high_memory.cpuprofile.zip

This part of code:

while(queue.length > 0) {
  const chunk = queue.dequeue();
  let availableModules = availableModulesMap.get(chunk);
  let changed = false;
  for(const parent of chunk.parentsIterable) {
    const availableModulesInParent = availableModulesMap.get(parent);
    if(availableModulesInParent !== undefined) {
      // If we know the available modules in parent: process these
      if(availableModules === undefined) {
        // if we have not own info yet: create new entry
        availableModules = new Set(availableModulesInParent);
        for(const m of parent.modulesIterable)
          availableModules.add(m);
        availableModulesMap.set(chunk, availableModules);
        changed = true;
      } else {
        for(const m of availableModules) {
          if(!parent.containsModule(m) && !availableModulesInParent.has(m)) {
            availableModules.delete(m);
            changed = true;
          }
        }
      }
    }
  }
  if(changed) {
    // if something changed: enqueue our children
    for(const child of chunk.chunksIterable)
      queue.enqueue(child);
  }
}

Takes lot of loops. I didn't measure time but it was running like 50000 times each iteration took around half second. I wasn't successful in finishing this operation at all since don't know when. But I guess since node.js updation from 8 to 9 (as was recommended me before). I'll try to finish this operation and share reports how log it takes on node 9 and then run again on node 8 and compare results.

Also Im open to communication via skype, hangouts or similar service, just let me know how and when.

Great job on getting those CPU profiles @pleerock! I think the high memory CPU log is the most accurate one because the other will have a lot of time spent on GC, and that doesn't really help narrow down the problem.

It looks like the seal hook is running into a lot of error cases:

@sokra is this information useful for you? I can jump on a hangouts with @pleerock and try some more advanced debugging if you can give us some directions.

@pleerock @filipesilva have you tried the fix in my PR?

I have not, no. I don't have access to the repo where the problem manifests. @pleerock can you try manually patching your local webpack node_modules with https://github.com/webpack/webpack/pull/6249/files?

@filipesilva I will. btw it was running since I posted my message (over 3hrs) and Im going to stop execution since I don't see the end (last time I run it with webpack3 and node9 was over 6hrs and I stopped execution as well)

So, its same with provided code. Problem is still in while cycle. In 10+ minutes it run 2500 cycles each iteration took 200ms in average. Profile results:

webpack4_extra_changes.cpuprofile.zip

Okay, I downgraded node from 9.3.0 to 8.9.4 and same while cycle iteration now takes ~50ms. As I previously told I wasn't able to finish serve process at all since I upgraded to node 9.

Results of running 10 minutes with node8:

webpack4_node8.cpuprofile.zip