Webpack 5 uses dramatically more memory than Webpack 4

Bug report

What is the current behavior?

We’ve been unable to migrate Zulip from webpack 4 to webpack 5 due to an enormous memory usage regression. Memory usage is important to us because many of our users are on VMs with just 2 GB RAM.

In an effort to debug this with as few variables and moving parts as possible, I deleted everything except our JavaScript and an extremely minimal nucleus of the webpack configuration. Then I ran each version of webpack several times, deleting the output and cache directories before each run. I observed that webpack 5 uses nearly 4 GB of memory on this benchmark, while webpack 4 used just 500 to 800 MB.

// webpack.config.js
const assets = require("./tools/webpack.assets.json");

module.exports = {
    mode: "production",
    context: __dirname,
    entry: assets,
};

If the current behavior is a bug, please provide the steps to reproduce.

Clone this branch, and observe the maxresident values from \time webpack:

$ git clone -b webpack-benchmark --depth=1 https://github.com/andersk/zulip.git
$ cd zulip
$ yarn
$ node_modules/.bin/webpack --version
webpack 5.38.1
webpack-cli 4.7.2
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack --stats=errors-only
311.76user 3.99system 0:36.50elapsed 864%CPU (0avgtext+0avgdata 3985384maxresident)k
7792inputs+23736outputs (0major+1287196minor)pagefaults 0swaps
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack --stats=errors-only
310.15user 3.76system 0:36.20elapsed 867%CPU (0avgtext+0avgdata 3805580maxresident)k
0inputs+23672outputs (0major+1263156minor)pagefaults 0swaps
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack --stats=errors-only
311.75user 3.95system 0:36.73elapsed 859%CPU (0avgtext+0avgdata 3918600maxresident)k
0inputs+23672outputs (0major+1284466minor)pagefaults 0swaps
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack --stats=errors-only
313.17user 3.91system 0:36.71elapsed 863%CPU (0avgtext+0avgdata 3819140maxresident)k
0inputs+23704outputs (0major+1263395minor)pagefaults 0swaps
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack --stats=errors-only
310.46user 3.89system 0:36.15elapsed 869%CPU (0avgtext+0avgdata 3887100maxresident)k
0inputs+23704outputs (0major+1283419minor)pagefaults 0swaps
$ yarn add webpack@^4
$ node_modules/.bin/webpack --version
webpack 4.46.0
webpack-cli 4.7.2
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack --stats=errors-only
234.98user 4.59system 0:33.39elapsed 717%CPU (0avgtext+0avgdata 658272maxresident)k
2072inputs+52072outputs (0major+1500173minor)pagefaults 0swaps
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack --stats=errors-only
235.43user 4.37system 0:33.13elapsed 723%CPU (0avgtext+0avgdata 519372maxresident)k
0inputs+52016outputs (0major+1438493minor)pagefaults 0swaps
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack --stats=errors-only
235.23user 4.36system 0:32.77elapsed 731%CPU (0avgtext+0avgdata 784472maxresident)k
0inputs+52008outputs (0major+1423157minor)pagefaults 0swaps
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack --stats=errors-only
237.57user 4.58system 0:33.16elapsed 730%CPU (0avgtext+0avgdata 780992maxresident)k
0inputs+52080outputs (0major+1487320minor)pagefaults 0swaps
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack --stats=errors-only
235.55user 4.48system 0:33.06elapsed 725%CPU (0avgtext+0avgdata 775600maxresident)k
0inputs+51984outputs (0major+1493409minor)pagefaults 0swaps

What is the expected behavior?

webpack 5 should have similar memory usage to webpack 4.

Other relevant information: webpack version: 5.38.1 Node.js version: 14.17.0 Operating System: NixOS 21.11 Additional tools: yarn 1.22.10

[andersk]

By bisecting commits in webpack and terser-webpack-plugin, I was able to attribute most of the memory usage regression to webpack-contrib/terser-webpack-plugin#344.

I found that patching terser-webpack-plugin to remove enableWorkerThreads: true reduces memory usage back to the range of Webpack 4, without a noticeable performance impact.

@alexander-akait FYI.

$ node_modules/.bin/webpack --version
webpack 5.38.1
webpack-cli 4.7.2
$ sed -i '/enableWorkerThreads/d' node_modules/terser-webpack-plugin/dist/index.js
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack-cli --stats=errors-only
311.26user 5.43system 0:36.25elapsed 873%CPU (0avgtext+0avgdata 675108maxresident)k
0inputs+23704outputs (0major+1511627minor)pagefaults 0swaps
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack-cli --stats=errors-only
312.24user 5.60system 0:36.35elapsed 874%CPU (0avgtext+0avgdata 671892maxresident)k
0inputs+23704outputs (0major+1585726minor)pagefaults 0swaps
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack-cli --stats=errors-only
312.78user 5.36system 0:36.48elapsed 871%CPU (0avgtext+0avgdata 675744maxresident)k
0inputs+23704outputs (0major+1549216minor)pagefaults 0swaps
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack-cli --stats=errors-only
310.10user 5.58system 0:36.41elapsed 866%CPU (0avgtext+0avgdata 675936maxresident)k
0inputs+23672outputs (0major+1565916minor)pagefaults 0swaps
$ rm -rf dist node_modules/.cache; \time node_modules/.bin/webpack-cli --stats=errors-only
312.80user 5.57system 0:36.14elapsed 880%CPU (0avgtext+0avgdata 674420maxresident)k
0inputs+23672outputs (0major+1549756minor)pagefaults 0swaps

[andersk]

@alexander-akait I did share the application and a full reproduction recipe in the original report above. Totally open source, Apache 2.0 license, no NDA necessary. ☺

@sokra Hmm. You seem to be right that time doesn’t measure what I thought it was measuring. It does measure over the entire child process tree, but it only reports the largest single process within that tree, rather than the total usage of all processes.

I found a tool cgmemtime that does measure the total usage. Based on that better measurement, the discrepancy between webpack 4 and webpack 5 still exists in the actual application, but it’s less dramatic, and doesn’t seem to be visible in this particular benchmark that I extracted.

I will close this report for now, do more experiments with cgmemtime, and open another report if I find something actionable. Feel free to hop into zulip/zulip#16649 if you’d like to follow along.

Thanks all!