Massive performance regression on 5.71.0 during initial script execution.

[jljorgenson18]

Hi,

I do not have a minimal repro case yet but just as an fyi, we are seeing a massive regression on our initial script execution when going from webpack version 5.70.0 to 5.71.0. Feel free to close this issue if there is no action to be had but our main bundle went from taking 38ms to execute all the way to 97ms. On mobile iOS, it's even worse.

I dug through the release notes and haven't been able to pinpoint the cause but I may try to update this ticket if I can find the culprit.

A few comments about our webpack config

• We have multi config system (https://webpack.js.org/configuration/configuration-types/#exporting-multiple-configurations)
• We are using babel with typescript, sass, and general assets types
• This is what we have set for our optimization field

    optimization: {
        minimizer: [new TerserPlugin({ extractComments: false }), new CssMinimizerPlugin()]
    },

• No source maps are sent with our production build
• There was no discernible difference in our bundle module sizes when using a bundle analyzer

I'll update this ticket if I find anything else

[alexander-akait]

Can yiu check it without minification? THere are many places, babel with core-js and polyfills and some polyfills can ahve regression, terser can change ouput and it can be bad for perf, typescript can generate other code, without reproducible repo hard to help you, sorry

[jljorgenson18]

@alexander-akait We just confirmed that without minification and when bundling in dev mode, the bundles are exactly the same.

I think we isolated the problem

The usage of the arrow function seems to be causing the issue. My guess is that the browser is moving over a massive bit of context and that ends up being a bottleneck on load. Just changing the arrow function to a normal function removed the perf issue. I'm not sure how webpack optimization does this and why, but it appears to be the problem.

[jljorgenson18]

I believe this was the commit where it broke

806ee08

I think this optimization should be reverted @vankop

[alexander-akait]

@jljorgenson18 You faced with it #13125, I recommend to disable arrow functions on your side (https://webpack.js.org/configuration/output/#outputenvironment, set arrowFunction to false) as a workaround, I think we should report this to Safari team, can you provide version of a browser?

[jljorgenson18]

@alexander-akait The problem isn't the overall usage of arrow functions, it's the arrow function that wrap all of the module code. That part is what seems slow and if I had to guess, it's probably due to forwarding the context. This also seems to specific to webpack optimization code and it isn't a problem with the internal webpack code generally.

This happens on both Safari and Chrome, but it probably happens in Firefox as well.

I sincerely doubt we are the only project experiencing this and I can try to find a large open source project tomorrow that is also having this occur. I would expect this to have a negative effect on any large bundle. This was already a tiny optimization related making bundles just the tiniest bit smaller so I think the right course of action is just to revert the change.

That being said, I do think it probably makes sense to report to this to Webkit and Chromium

Edit: We didn't actually confirm it happened on Safari yet

[vankop]

could you provide both profiles without arrow function and with it?

[jljorgenson18]

@vankop My screenshots in the initial post show the performance profile times. Do you want them exported some other way and do you want a working example from an open source project?

[Rush]

Is there a workaround for this issue? Is it an issue with UMD output only?

[vankop]

@Rush set output.environment.arrowFunction=false, see https://webpack.js.org/configuration/output/#outputenvironment . this should help

[sod]

Could you also test with wrapping the section with console.time('bootstrap') & console.timeEnd('bootstrap') with dev tools closed, and then inspect the console output afterwards?

Having a debugger attached can slow down specific kind of code considerably because the browser has to keep the context of functions in case you halt the program.

If console.time('bootstrap'), console.timeEnd('bootstrap') spits out the same time with & without arrow functions, then your customers shouldn't be affected by it.

[jljorgenson18]

Sorry for the delay. @sod using what you suggested, I confirmed that the issue is still definitely there. Currently on our bundle without minification, bootstrap takes about 160ms with arrow functions and about 120ms without if you completely wrap the entire bundle.

This is a really simple fix if you just remove arrow functions from the top wrapping UMD function during minification

[jljorgenson18]

Just checked with minification and by using the arrowFunction output environment config. I am seeing about 55ms for bootstrap with arrow functions set to false and about 130ms with arrow functions set to true

[alexander-akait]

@jljorgenson18 I wrote about it here above (#13125)

[jljorgenson18]

@alexander-akait right, but this is a special case of that issue. An optimization was added here 806ee08 which caused an even worse regression for large UMD bundles.

[alexander-akait]

@jljorgenson18 I think we should report about it to v8 bug tracker, that is really bad for JS ecosystem, not only for webpack

[webpack-bot]

This issue had no activity for at least three months.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[webpack-bot]

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.