Improve production build times

[filipesilva]

This PR adds cache support for UglifyJS and Build Optimizer, and executes Build Optimizer in parallel.

Benchmarks for ng build --prod:

• new project
  • before: 16270 ms
  • after (no cache): 17283 ms (+6%)
  • after (with cache): 7040 ms (-56%)
• big project (https://github.com/filipesilva/angular-cli-test-repo)
  • before: 629958 ms
  • after (no cache): 571516 ms (-9%)
  • after (with cache): 456342 ms (-28%)

[Toxicable]

@filipesilva
Looking at https://github.com/amireh/happypack#threads-number
Could you try bench-marking it with threads set to 4?

[Toxicable]

Also since we're adding a cache could we see some RAM benchmarks?

[clydin]

Using the number of cpu cores would probably be a good idea. Too many threads will end up hurting performance due to excessive context switching and too little will limit the potential performance improvement.

[Toxicable]

Since according to the readme there's diminishing returns after 4, I think something like this would be best

const cpus = require('os').cpus().length;
const happyCores = cpus > 4 ? 4 : cpus;

[clydin]

Most likely because the tests were run on a quad core system which would make 4 the best number to use. Especially since the readme says performance started to really suffer after 8.

[Toxicable]

@clydin Possibly, I think it would be worth doing our own analysis either way since this could be a big factor on the final speed

[filipesilva]

I tried adding the CPU config to the same that uglifyjs-webpack-plugin uses, which in my case will be 7:

    extraPlugins.push(new HappyPack({
      verbose: false,
      threads: require('os').cpus().length - 1,

Then I ran cleared node_modules and ran 2 prod builds in a row:

• default number of threads
  • no cache: 548029 ms (~9.1 minutes)
  • with cache: 479455 ms (~7.9 minutes)
• 7 threads
  • no cache: 559157 ms (~9.3 minutes)
  • with cache: 454367 ms (~7.5 minutes)

I also tried a new project:

• default number of threads
  • no cache: 15617 ms (~16 seconds)
  • with cache: 6350 ms (~6 seconds)
• 7 threads
  • no cache: 16393 ms (~16 seconds)
  • with cache: 7527 ms (~8 seconds)

Doesn't seem a big difference overall. But I think making it variable it might be worth it for some environments with less than 3 CPUs to avoid spawning more threads than needed, but probably defaulting to 1 if there's just one CPU.

PR is amended accordingly.

[filipesilva]

I removed the parallelization to reduce risk since it looks like cache is what provided the bigger benefit.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}