Commenting out new webpack.optimize.ModuleConcatenationPlugin(), in webpack.config.js results in
peak 1.8GB memory usage.

npm run ngc is necessary because it also generates some files in node_modules/ that are
imported by the app.

The app has a 12 lazy loaded chunks by default.
These can be imported into the main chunk by editing src/app/app-routing.module.js (after npm run ngc), commenting out the System.import: and uncommenting import declarations as shown in the repo readme. This will increase memory usage further.

At this point I stopped because I don't think my computer could take the memory usage of both the webpack process and the chrome profiler together without having to aggressively garbage collect (which would mess with the profile numbers).

Worth noting that 1-import is a bit of an odd case because it's a smaller lazy module (/cg/cg.module.ngfactory.js). The modX/modX.module.ngfactory.js ones are all the same size (350ish modules).

Analyzing the CPU profiles shows growing time being used by the same functions:

2-import:

7-import:

dep.module.reasons.forEach.reason and _orderedConcatenationList.map.info are both in ./lib/optimize/ModuleConcatenationPlugin.js and see growing time spent. DoJoin and writeUtf8String are native functions but also seem to be used more and more.

Looking at the heap profiles it seems that the native stringSlice is what's eating up all the memory, followed by DoJoin:

This string can get very, very big when there's a bunch of modules concatenated together. And everywhere that a module is used, if it's inside the concatenated module, it also uses the same identifier.

So if you had 350 modules their identifiers were, say, a path of 100 character length each. Now all those modules are inside a single concatenated module. The identifier of that concatenated module is 350 * 100 = 35,000 characters. That identifier is being used in at least 350 places, so at least 350 * 35,000 = 12,250,000 extra characters.

Changing this identifier to be a small string instead lowers the memory usage for the original repro from 17GB to 2.8GB.

Will put up a PR.

Special thanks to @clydin that pointed me at the increased size of the stats files and how it could be related to this problem.