Optimising build performance, initial: 40s, incremental: 6s #1574

Closed
janpaul123 opened this Issue Nov 1, 2015 · 26 comments

Comments

Projects
None yet
@janpaul123

So at @brigade our build times are pretty slow, and I can't seem to figure out why this is. We use Babel, SCSS+autoprefixer+css-loader+style-loader, react+react-hot-loader, CommonsChunkPlugin, DefinePlugin, webpack-dev-server, devtool:'eval-cheap-module-source-map', and that's pretty much it. I posted a typical version of our config at the end.

I initially started investigating the incremental build time, since I run into that most often. These are the things I tried that didn't help:

  • Don't use context.
  • Use include in config to remove large directories from path (we already used exclude in some places, so this didn't help)
  • Scoping react-hot-loader only to components directory.
  • Remove hash from css filenames.

Here are some things that did help:

  • Disabling source maps altogether (large effect on emit and creating chunk assets).
  • Pulling more modules into the common chunk (mostly affected emit, but this was trumped by disabling source maps altogether; no compound effect).

Most of the time for incremental builds was still in build modules though, I could only affect create chunk assets and emit this way. Then I tried to tackle the initial build, assuming there must be some sort of more structural flaw in our codebase. First I reset the codebase back to the way it was before I played with incremental builds. Then my methodology was to then try something, then run webpack 5 times and save that total time, and also save the stats from one of the runs to get some insight. I didn't reset the code base in between builds, but tried to compound improvements to get the time down as much as possible. Here's the result of that investigation:

Baseline:
43748ms build modules
110ms seal
144ms optimize
244ms hashing
3621ms create chunk assets
12ms additional chunk assets
0ms optimize chunk assets
1ms optimize assets
1203ms emit
./profile.sh  244.24s user 10.78s system 99% cpu 4:16.90 total

Removing load postfixes (see https://github.com/elastic/kibana/blob/c9c9e565e6f744ba3fbc959cd0ac81a7b28a476d/src/optimize/BaseOptimizer.js and https://github.com/webpack/webpack/issues/24):
43254ms build modules
94ms seal
131ms optimize
223ms hashing
3310ms create chunk assets
10ms additional chunk assets
0ms optimize chunk assets
1ms optimize assets
1331ms emit
./profile.sh  243.28s user 10.63s system 99% cpu 4:15.42 total
NO DIFFERENCE

More messing around with resolve params:
41777ms build modules
104ms seal
143ms optimize
243ms hashing
3010ms create chunk assets
12ms additional chunk assets
0ms optimize chunk assets
1ms optimize assets
1620ms emit
./profile.sh  239.57s user 10.91s system 96% cpu 4:20.16 total
NO DIFFERENCE

Reducing number of modulesDirectories to 5:
36639ms build modules
125ms seal
144ms optimize
255ms hashing
3878ms create chunk assets
17ms additional chunk assets
0ms optimize chunk assets
1ms optimize assets
857ms emit
./profile.sh  212.82s user 9.79s system 92% cpu 4:00.07 total
HELPS MAYBE?

Reducing number of modulesDirectories to 3:
42700ms build modules
92ms seal
246ms optimize
174ms hashing
2650ms create chunk assets
14ms additional chunk assets
0ms optimize chunk assets
0ms optimize assets
1036ms emit
./profile.sh  218.80s user 9.69s system 97% cpu 3:53.51 total
HELPS MAYBE?

Include components_loader.js regex in webpack config:
47551ms build modules
69ms seal
90ms optimize
209ms hashing
2509ms create chunk assets
8ms additional chunk assets
1ms optimize chunk assets
0ms optimize assets
1475ms emit
./profile.sh  221.16s user 9.72s system 96% cpu 3:58.70 total
NO DIFFERENCE?

Disable SCSS source maps:
30114ms build modules
102ms seal
124ms optimize
205ms hashing
2897ms create chunk assets
14ms additional chunk assets
0ms optimize chunk assets
1ms optimize assets
860ms emit
./profile.sh  196.68s user 8.60s system 100% cpu 3:25.27 total
SOME DIFFERENCE! (same as with the incremental build)

Disable source maps altogether:
37089ms build modules
105ms seal
126ms optimize
239ms hashing
467ms create chunk assets
13ms additional chunk assets
0ms optimize chunk assets
1ms optimize assets
510ms emit
./profile.sh  198.85s user 9.73s system 97% cpu 3:34.86 total
NO DIFFERENCE?

Extracting more code into a common chunk:
35174ms build modules
81ms seal
168ms optimize
91ms hashing
195ms create chunk assets
16ms additional chunk assets
0ms optimize chunk assets
1ms optimize assets
337ms emit
./profile.sh  182.06s user 8.63s system 97% cpu 3:16.42 total
HELPS MAYBE?

De-duplicate core-js:
35300ms build modules
116ms seal
217ms optimize
123ms hashing
234ms create chunk assets
34ms additional chunk assets
0ms optimize chunk assets
1ms optimize assets
270ms emit
./profile.sh  189.18s user 8.86s system 98% cpu 3:21.99 total
NO DIFFERENCE?

Use React.js binary:
40170ms build modules
116ms seal
222ms optimize
122ms hashing
270ms create chunk assets
13ms additional chunk assets
0ms optimize chunk assets
1ms optimize assets
302ms emit
./profile.sh  185.07s user 8.53s system 99% cpu 3:15.09 total
NO DIFFERENCE?

So the only new thing I tried that helped was reducing the number of modulesDirectories.

Some more information. Here is what a typical incremental build looks like (with hot loading enabled), after all the changes above:

[webpack] webpack: bundle is now INVALID.
3657ms build modules  
83ms seal
1247ms optimize
147ms hashing
276ms create chunk assets
156ms additional chunk assets
0ms optimize chunk assets 
0ms optimize assets 
196ms emit
[webpack] Hash: b91dce65a3b67a9d69d9
[webpack] Version: webpack 1.12.2
[webpack] Time: 5805ms
[webpack]                                Asset      Size  Chunks             Chunk Names
[webpack]                     intl_polyfill.js   1.17 MB       4  [emitted]  intl_polyfill
[webpack]                   jquery_fallback.js   1.26 MB       5  [emitted]  jquery_fallback
[webpack]                            vendor.js   6.09 MB       8  [emitted]  vendor
[webpack] 8.a5cd34b7ba7171bb6548.hot-update.js    2.4 kB       8  [emitted]  vendor
[webpack] a5cd34b7ba7171bb6548.hot-update.json  36 bytes          [emitted]  
[webpack] chunk    {0} activity_map.js (activity_map) 188 kB {8}
[webpack]      + 7 hidden modules
[webpack] chunk    {1} admin.js (admin) 141 kB {2}
[webpack]      + 36 hidden modules
[webpack] chunk    {2} application.js (application) 69.2 kB {8}
[webpack]      + 24 hidden modules
[webpack] chunk    {3} diffux_ci.js (diffux_ci) 295 kB {8}
[webpack]  [1829] ./app/assets/components -diffux\.jsx$ 5.12 kB {3} [built]
[webpack]        ... -> factory:3ms building:0ms
[webpack]      + 116 hidden modules
[webpack] chunk    {4} intl_polyfill.js (intl_polyfill) 1.12 MB [rendered]
[webpack]      + 74 hidden modules
[webpack] chunk    {5} jquery_fallback.js (jquery_fallback) 1.21 MB [rendered]
[webpack]      + 69 hidden modules
[webpack] chunk    {6} partners.js (partners) 543 kB {2}
[webpack]      + 199 hidden modules
[webpack] chunk    {7} specs.js (specs) 1.67 MB {8}
[webpack]  [2201] ./app/assets/components -test\.jsx$ 8.84 kB {7} [built]
[webpack]        ... -> factory:9ms building:0ms
[webpack]      + 358 hidden modules
[webpack] chunk    {8} vendor.js, 8.a5cd34b7ba7171bb6548.hot-update.js (vendor) 6.08 MB [rendered]
[webpack]   [584] ./app/assets/components/CardButtons/index.jsx 2.35 kB {8} [built]
[webpack]        ... -> factory:1ms building:0ms dependencies:1ms
[webpack]      + 1768 hidden modules
[webpack] webpack: bundle is now VALID.

This is a simplified but representative version of webpack.config.js that I ended up with:

require('babel-core/polyfill');
var webpack = require('webpack');

module.exports = {
  entry: {
    activity_map: './app/assets/_activity_map.js',
    admin: './app/assets/_admin.js',
    application: [
      'webpack-dev-server/client?http://localhost:8080',
      './app/assets/_application.js'
    ],
    intl_polyfill: './app/assets/_intl_polyfill.js',
    jquery_fallback: './app/assets/_jquery_fallback.js',
    partners: './app/assets/_partners.js',
    vendor: './app/assets/_vendor.js',
    specs: [
      'webpack-dev-server/client?http://localhost:8080',
      './app/assets/spec/_specs.js'
    ],
    diffux_ci: './app/assets/spec/_diffux_ci.js',
  },

  output: {
    path: __dirname + '/public/assets',
    filename: '[name].js',
    publicPath: 'http://localhost:8080/assets'
  },

  resolve: {
    modulesDirectories: [
      'app/assets',
      'vendor/assets/bower_components',
      'node_modules',
    ],
    extensions: [
      '.jsx',
      '.js',
      '',
    ],
    loaderExtensions: ['.js', ''],
    loaderPostfixes: [''],
    unsafeCache: true,
    postfixes: [''],
    alias: {
      'core-js': __dirname + '/node_modules/babel-runtime/node_modules/core-js',
      'react$': __dirname + '/node_modules/react/dist/react-with-addons.js',
    },
  },

  // Disable source maps for now
  // devtool: 'eval-cheap-module-source-map',

  plugins: [
    new webpack.DefinePlugin({
      // Some definitions here
    }),
    new webpack.optimize.CommonsChunkPlugin({
      name: 'application',
      minChunks: 2,
      chunks: ['admin', 'partners']
    }),
    new webpack.optimize.CommonsChunkPlugin({
      name: 'vendor',
      minChunks: 2,
      chunks: ['application', 'diffux_ci', 'specs', 'activity_map'],
    }),
  ],

  externals: {
    jquery:  'jQuery',
  },

  module: {
    loaders: [
      {
        test: /\.css$/,
        loader: 'style!css?localIdentName=[path][name]--[local]--[hash:base64:10]!autoprefixer',
        include: [
          __dirname + '/app/assets',
          __dirname + '/node_modules/normalize.css',
        ],
      },
      {
        test: /\.scss$/,
        loader: 'style!css?localIdentName=[path][name]--[local]--[hash:base64:10]!autoprefixer!sass',
        include: __dirname + '/app/assets',
      },
      {
        test: /\.jsx?$/,
        loaders: [
          'babel-loader?cacheDirectory',
          'react-hot'
        ],
        exclude: [/node_modules/, /bower_components/, /support\/fixtures/],
        include: __dirname + '/app/assets',
      },
      {
        test: /app\/assets\/components\/(.*?)(?:\/index)?\.jsx/,
        loader: __dirname + '/app/assets/components_loader',
        include: __dirname + '/app/assets/components',
      },
      {
        test: /raven-js/,
        loaders: ['imports?this=>window'],
        include: __dirname + '/node_modules/raven-js',
      },
      {
        test: /\.(gif|jpe?g|png|svg)$/,
        loader: 'file-loader',
        include: __dirname + '/app/assets',
      },
      {
        test: /\.json$/,
        loader: 'json-loader',
        include: __dirname + '/app/assets',
      }
    ],
    noParse: [
      /acorn\/dist\/acorn\.js$/,
      /underscore\/underscore\.js$/,
      /react-with-addons\.js$/,
    ]
  },

  profile: true,
  stats: {
    hash: true,
    version: true,
    timings: true,
    assets: true,
    chunks: true,
    modules: true,
    reasons: true,
    children: true,
    source: false,
    errors: true,
    errorDetails: true,
    warnings: true,
    publicPath: true
  },
};

The components_loader is just something small that we added for exposing components so we can more easily include them in our style guide:

module.exports = function(content) {
  if (this.cacheable) {
    this.cacheable();
  }

  const matches = this.resourcePath.match(/components\/(.*?)(?:\/index)?\.jsx/);
  if (!matches) {
    return content;
  }

  return content + '\n' +
    'window.ReactComponents = window.ReactComponents || {};\n' +
    "ReactComponents['" + matches[1] + "'] = module.exports;\n";
};

The full stats.json can be found here: https://gist.github.com/d8feb05513656472dbf5

I really hope someone can help me with this, I've been stuck on this issue for two days now. Maybe if we find a solution it would help others as well, because I think our React/Babel/SCSS setup is pretty common. Thanks!!

@bebraw

This comment has been minimized.

Show comment
Hide comment
@bebraw

bebraw Nov 2, 2015

Member

Quick note. I heard there was a big performance regression at css-loader after 0.14 (last fast version). It has to do with CSS Modules support and the fact that it has to do some extra work through postcss now. I'm not sure if it's applicable to your case but you could try to restrict it to 0.14 and see if there's any difference.

I'm in the same boat with a project of mine. There are likely a lot of easy ways to optimize it further.

Member

bebraw commented Nov 2, 2015

Quick note. I heard there was a big performance regression at css-loader after 0.14 (last fast version). It has to do with CSS Modules support and the fact that it has to do some extra work through postcss now. I'm not sure if it's applicable to your case but you could try to restrict it to 0.14 and see if there's any difference.

I'm in the same boat with a project of mine. There are likely a lot of easy ways to optimize it further.

@janpaul123

This comment has been minimized.

Show comment
Hide comment
@janpaul123

janpaul123 Nov 2, 2015

Interesting, thanks for the suggestion. Downgrading to css-loader@0.14.0 does seem to help a bit.

33925ms build modules       
119ms seal
206ms optimize
101ms hashing
294ms create chunk assets
14ms additional chunk assets
0ms optimize chunk assets 
0ms optimize assets 
542ms emit
./profile.sh  160.87s user 7.98s system 100% cpu 2:48.73 total

Interesting, thanks for the suggestion. Downgrading to css-loader@0.14.0 does seem to help a bit.

33925ms build modules       
119ms seal
206ms optimize
101ms hashing
294ms create chunk assets
14ms additional chunk assets
0ms optimize chunk assets 
0ms optimize assets 
542ms emit
./profile.sh  160.87s user 7.98s system 100% cpu 2:48.73 total
@bebraw

This comment has been minimized.

Show comment
Hide comment
@bebraw

bebraw Nov 2, 2015

Member

Upgrading to Babel 6 should give 10-20% gain. It was released just a few days ago and not all plugins aren't up to date yet.

You can also try DLLs. See the example. I haven't tried this solution yet. I think pushing your vendor deps there could help somewhat.

Member

bebraw commented Nov 2, 2015

Upgrading to Babel 6 should give 10-20% gain. It was released just a few days ago and not all plugins aren't up to date yet.

You can also try DLLs. See the example. I haven't tried this solution yet. I think pushing your vendor deps there could help somewhat.

@janpaul123

This comment has been minimized.

Show comment
Hide comment
@janpaul123

janpaul123 Nov 2, 2015

Yeah, we'll be upgrading. I did consider DLLs, but I'm mostly baffled by the long incremental build time. Incremental builds take several seconds in the "build modules" phase, even if only one file changed (see the example in my original post). How can that be?

On 2 nov. 2015, at 09:04, Juho Vepsäläinen notifications@github.com wrote:

Upgrading to Babel 6 should give 10-20% gain. It was released just a few days ago and not all plugins aren't up to date yet.

You can also try DLLs. See the example. I haven't tried this solution yet. I think pushing your vendor deps there could help somewhat.


Reply to this email directly or view it on GitHub.

Yeah, we'll be upgrading. I did consider DLLs, but I'm mostly baffled by the long incremental build time. Incremental builds take several seconds in the "build modules" phase, even if only one file changed (see the example in my original post). How can that be?

On 2 nov. 2015, at 09:04, Juho Vepsäläinen notifications@github.com wrote:

Upgrading to Babel 6 should give 10-20% gain. It was released just a few days ago and not all plugins aren't up to date yet.

You can also try DLLs. See the example. I haven't tried this solution yet. I think pushing your vendor deps there could help somewhat.


Reply to this email directly or view it on GitHub.

@bebraw

This comment has been minimized.

Show comment
Hide comment
@bebraw

bebraw Nov 2, 2015

Member

@janpaul123 That's something I would love to understand. I'm seeing relatively long rebuild times on my project too especially when the amount of files grows on a site. It could be the same problem. We need to understand better what it actually does on rebuild to get a good hang of this.

Member

bebraw commented Nov 2, 2015

@janpaul123 That's something I would love to understand. I'm seeing relatively long rebuild times on my project too especially when the amount of files grows on a site. It could be the same problem. We need to understand better what it actually does on rebuild to get a good hang of this.

@janpaul123

This comment has been minimized.

Show comment
Hide comment
@janpaul123

janpaul123 Nov 3, 2015

Yeah, maybe @sokra can enlighten us why this is happening?

Yeah, maybe @sokra can enlighten us why this is happening?

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Nov 4, 2015

Member

I see the problem, but currently I don't know why the "build modules" times are so high. Maybe because the access to the cache is too slow. This need to be profiled.

I think this could be problem which can be solved. I try to build a repro case for me.

Member

sokra commented Nov 4, 2015

I see the problem, but currently I don't know why the "build modules" times are so high. Maybe because the access to the cache is too slow. This need to be profiled.

I think this could be problem which can be solved. I try to build a repro case for me.

@jnwng

This comment has been minimized.

Show comment
Hide comment
@jnwng

jnwng Nov 5, 2015

Contributor

@sokra the test case provided in #1530 (repo here: https://github.com/tvararu/webpack-test) is a good reproduction of the "many modules being rebuilt" case - might help you diagnose a possible increase in incremental build times.

Contributor

jnwng commented Nov 5, 2015

@sokra the test case provided in #1530 (repo here: https://github.com/tvararu/webpack-test) is a good reproduction of the "many modules being rebuilt" case - might help you diagnose a possible increase in incremental build times.

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Nov 5, 2015

Member

@jnwng Thanks

Member

sokra commented Nov 5, 2015

@jnwng Thanks

@Restuta

This comment has been minimized.

Show comment
Hide comment
@Restuta

Restuta Nov 6, 2015

@bebraw is there an issue to follow regarding mentioned degrade in performance of css-loader from v0.14?

Restuta commented Nov 6, 2015

@bebraw is there an issue to follow regarding mentioned degrade in performance of css-loader from v0.14?

@bebraw

This comment has been minimized.

Show comment
Hide comment
Member

bebraw commented Nov 6, 2015

@bebraw bebraw added the question label Nov 14, 2015

@janpaul123

This comment has been minimized.

Show comment
Hide comment
@janpaul123

janpaul123 Nov 17, 2015

@lencioni found a quick fix to reduce incremental build times to ~2.3s, by moving most moduleDirectories to root (except node_modules); see #472 (comment). Added note in the docs here: https://github.com/webpack/docs/wiki/build-performance/99b3c2758589c35d62c3cdc03e312682de31dd6b!

@lencioni found a quick fix to reduce incremental build times to ~2.3s, by moving most moduleDirectories to root (except node_modules); see #472 (comment). Added note in the docs here: https://github.com/webpack/docs/wiki/build-performance/99b3c2758589c35d62c3cdc03e312682de31dd6b!

@justingreenberg justingreenberg referenced this issue in erikras/react-redux-universal-hot-example Jan 21, 2016

Closed

Folder structure, modules/ducks, best practices #169

@vjpr

This comment has been minimized.

Show comment
Hide comment
@vjpr

vjpr Feb 27, 2016

DllPlugin is the way to go. See here: erikras/react-redux-universal-hot-example#616

vjpr commented Feb 27, 2016

DllPlugin is the way to go. See here: erikras/react-redux-universal-hot-example#616

@trueter

This comment has been minimized.

Show comment
Hide comment
@trueter

trueter Mar 11, 2016

HappyPack is a lot easier to set up then the DLL plugin and can provide similar benefits. Combination with the DLL Plugin is possible, too.

trueter commented Mar 11, 2016

HappyPack is a lot easier to set up then the DLL plugin and can provide similar benefits. Combination with the DLL Plugin is possible, too.

blowery added a commit to Automattic/wp-calypso that referenced this issue Mar 17, 2016

Webpack: Use a root instead of a module directory for client
This shaves about 10s off of the initial build on my laptop. See webpack/webpack#1574 (comment) for details on why this might help.

blowery added a commit to Automattic/wp-calypso that referenced this issue Mar 18, 2016

Webpack: Use a root instead of a module directory for client
This shaves about 10s off of the initial build on my laptop. See webpack/webpack#1574 (comment) for details on why this might help.

@blowery blowery referenced this issue in Automattic/wp-calypso Mar 20, 2016

Merged

Reader: Fix sharing to some Jetpack sites #4180

@ctrlplusb

This comment has been minimized.

Show comment
Hide comment
@ctrlplusb

ctrlplusb Sep 21, 2016

I set up HappyPack and a DLL plugin, which led to a 78% increase in build perf.

Side note: I am using webpack 2.

I set up HappyPack and a DLL plugin, which led to a 78% increase in build perf.

Side note: I am using webpack 2.

@AlexGalays

This comment has been minimized.

Show comment
Hide comment
@AlexGalays

AlexGalays Sep 24, 2016

Unfortunately, HappyPack doesn't work with any of the typescript loaders :(

Unfortunately, HappyPack doesn't work with any of the typescript loaders :(

@tizmagik

This comment has been minimized.

Show comment
Hide comment
@tizmagik

tizmagik Oct 5, 2016

@ctrlplusb are you able to share your recipe?

tizmagik commented Oct 5, 2016

@ctrlplusb are you able to share your recipe?

@ctrlplusb

This comment has been minimized.

Show comment
Hide comment
@ctrlplusb

ctrlplusb Oct 5, 2016

@tizmagik - I plan to add this to my open source react starter kit soonish.

@tizmagik - I plan to add this to my open source react starter kit soonish.

@tizmagik tizmagik referenced this issue in NYTimes/kyt Oct 5, 2016

Open

Speed up build/compilation #216

@trueter

This comment has been minimized.

Show comment
Hide comment
@trueter

trueter Oct 5, 2016

@AlexGalays I posted posted some slides back in April regarding configuration of HappyPack and DLL Bundles with Webpack 1.
http://www.slideshare.net/trueter/how-to-make-your-webpack-builds-10x-faster
You can find the "recipe" here: https://gist.github.com/trueter/0e861403e59a9e27a476f3ad7ada1a89

trueter commented Oct 5, 2016

@AlexGalays I posted posted some slides back in April regarding configuration of HappyPack and DLL Bundles with Webpack 1.
http://www.slideshare.net/trueter/how-to-make-your-webpack-builds-10x-faster
You can find the "recipe" here: https://gist.github.com/trueter/0e861403e59a9e27a476f3ad7ada1a89

@qbaty

This comment has been minimized.

Show comment
Hide comment
@qbaty

qbaty Oct 17, 2016

I used everything I can to improve webpack building performance, but i built 485 modules still costs me 20s. The time was like 60s or 50s+ before I optimized it.

  • I used dllPlugin & dllReferencePlugin even used it on my bootstrap-css, so I did not have to pack any common css & js
  • I used happypack for my vue-loader & babel-loader, 4 threads
  • I use webpack-uglify-parallel instead of webpack.optimize.UglifyJsPlugin
  • I disabled source-map
  • I extract my common code to the parent module from children modules

And I upload my profile to analyze it, except the Long module build chains I got nothing.
stats.json.zip

qbaty commented Oct 17, 2016

I used everything I can to improve webpack building performance, but i built 485 modules still costs me 20s. The time was like 60s or 50s+ before I optimized it.

  • I used dllPlugin & dllReferencePlugin even used it on my bootstrap-css, so I did not have to pack any common css & js
  • I used happypack for my vue-loader & babel-loader, 4 threads
  • I use webpack-uglify-parallel instead of webpack.optimize.UglifyJsPlugin
  • I disabled source-map
  • I extract my common code to the parent module from children modules

And I upload my profile to analyze it, except the Long module build chains I got nothing.
stats.json.zip

@ctrlplusb

This comment has been minimized.

Show comment
Hide comment
@ctrlplusb

ctrlplusb Oct 17, 2016

@qbaty I note that you including the UglifyJsPlugin in your optimisation. Does this mean that you are attempting to optimise your production build?

Personally I am only trying to optimise my development build as I find this is the area that where the build times hit me the most - the initial and then the incremental.

I would suggest not worrying about the production build performance too much. :)

How much time does your development build take?

@qbaty I note that you including the UglifyJsPlugin in your optimisation. Does this mean that you are attempting to optimise your production build?

Personally I am only trying to optimise my development build as I find this is the area that where the build times hit me the most - the initial and then the incremental.

I would suggest not worrying about the production build performance too much. :)

How much time does your development build take?

@qbaty

This comment has been minimized.

Show comment
Hide comment
@qbaty

qbaty Oct 17, 2016

@ctrlplusb Yep, It is production build.
Development building took 764ms. I think because I only change the code a little bit, so building is so quick. If run dev server from begin, still will cost 19s
image

qbaty commented Oct 17, 2016

@ctrlplusb Yep, It is production build.
Development building took 764ms. I think because I only change the code a little bit, so building is so quick. If run dev server from begin, still will cost 19s
image

@csvan csvan referenced this issue in angular-fullstack/generator-angular-fullstack Nov 12, 2016

Closed

Incremental builds are slow #2342

1 of 1 task complete
@motin

This comment has been minimized.

Show comment
Hide comment
@motin

motin Jan 23, 2017

@janpaul123 Could you share your ./profile.sh script? It does not show up on google, nor in https://gist.github.com/janpaul123 :) Thanks

motin commented Jan 23, 2017

@janpaul123 Could you share your ./profile.sh script? It does not show up on google, nor in https://gist.github.com/janpaul123 :) Thanks

@janpaul123

This comment has been minimized.

Show comment
Hide comment
@janpaul123

janpaul123 Feb 5, 2017

Ah, too long ago, couldn't find it any more, sorry!

Ah, too long ago, couldn't find it any more, sorry!

@WisestCoder

This comment has been minimized.

Show comment
Hide comment
@WisestCoder

WisestCoder Sep 14, 2017

There is an article that can solve the same problem,but is only for chinese
dushao103500/blog#2

There is an article that can solve the same problem,but is only for chinese
dushao103500/blog#2

@evilebottnawi

This comment has been minimized.

Show comment
Hide comment
@evilebottnawi

evilebottnawi May 15, 2018

Member

A lot of difference problem with perf als issue is very old. Closing due to inactivity. Please test with latest webpack version and feel free to create new issue if you still have problem with perf with minimum reproducible test repo. Thanks!

Member

evilebottnawi commented May 15, 2018

A lot of difference problem with perf als issue is very old. Closing due to inactivity. Please test with latest webpack version and feel free to create new issue if you still have problem with perf with minimum reproducible test repo. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment