Closed kemsky closed 3 years ago
JoostK
commented
3 years ago I am having little luck with loading the profiling events into chrome://tracing (it stays empty).
@kemsky if you are able to run with a debugger and then record a profiling session, that would be very helpful.
kemsky
commented
3 years ago @JoostK, I was not able to load it either. I tried recording on node 14.17 but it crashes at the very beginning. Ok, will try to do it using a debugger.
JoostK
commented
3 years ago After some debugging of Chrome's tracing tool, it appears that the +600MB of tracing data exceeds the maximum string length π€£ https://github.com/v8/v8/commit/ea56bf5513d0cbd2a35a9035c5c2996272b8b728. Importing the file itself just results in an empty string, whereas loading the zip crashes during decompression when all uncompressed bytes are converted into a single string.
kemsky
commented
3 years ago @JoostK, JSON contains a simple array, so you can cut it if necessary into two parts.
joshwiens
commented
3 years ago I'm having the same issue with build times, the initial report looks to be fairly thorough but feel free to @ me if you would like further tracing / info.
JoostK
commented
3 years ago With some sed magic to remove the common path prefix I managed to get the trace size down to fit:
Unfortunately I can't make a comparison with 11 as I don't have a trace for that run, but Webpack processing itself is now longer than the full build took before.
The pruned trace ~can be downloaded here~ can be downloaded as a much smaller zip here (only available for a week).
JoostK
commented
3 years ago I am not sure how to proceed here. We'd likely still need some runnable reproduction in order to establish what can be done to improve the situation here. If anyone can share a repro privately that would be super helpful.
joshwiens
commented
3 years ago @JoostK - Mine is a fairly large monorepo, I'll get to work on a repo you can access that is a bit more focused. Give me a hour or two
JoostK
commented
3 years ago @JoostK - Mine is a fairly large monorepo, I'll get to work on a repo you can access that is a bit more focused. Give me a hour or two
Thanks. Also take your time as it's almost 2 AM for me so I'm calling it a day!
kemsky
commented
3 years ago @JoostK, this is v11 profile: https://link.nithins.me/9NfVUS9T
I'm not sure if these are comparable...
Devtools are crashing also, I can only take a partial profile.
joshwiens
commented
3 years ago @kemsky - You can either give v8 more memory globally or chrome itself.
Globally ( imo the useful way ): NODE_OPTIONS=--max_old_space_size=8192 To Chrome: Chrome.app --args --js-flags="--max_old_space_size=8192"
joshwiens
commented
3 years ago @JoostK - I threw a new v11 CLI app up, added material and a basic component so it imports some styles. It's super minimal but should work for a reproduction, if not i'll just get you collab access to my work repo to poke around.
Main branch is cli v11.2.13 (~6000ms --prod) and upgrade-v12 is that branch upgraded. (~13200ms --prod).
JoostK
commented
3 years ago @JoostK, this is v11 profile: https://link.nithins.me/9NfVUS9T
I'm not sure if these are comparable...
Devtools are crashing also, I can only take a partial profile.
Not sure how to interpret those results. The angular-compiler block stays the same across v11 vs v12 which is to be expected, but what follows is so vastly different that I can't say what the real problem is. Terser is reported surprisingly differently in a way that in v12 it spans 60s vs just 10s in v11, but that may just be because the profiling events are generated differently. Additionally, the v11 trace spans almost 6 minutes vs 3.5 minutes in the v12 trace, so that's suspicious as well (especially because the angular-compiler trace has stayed consistent)
JoostK
commented
3 years ago @JoostK - I threw a new v11 CLI app up, added material and a basic component so it imports some styles. It's super minimal but should work for a reproduction, if not i'll just get you collab access to my work repo to poke around.
Main branch is cli v11.2.13 (~6000ms --prod) and upgrade-v12 is that branch upgraded. (~13200ms --prod).
Okay so I tried this and I'm actually getting similar times for v11 and v12, however in v11 the Terser processing is cached whereas in v12 it doesn't appear to be. This results in inconsistent results for v11, as cold runs are ~12s vs ~7s for cached runs; unlike v12 which always takes ~12s.
alan-agius4
commented
3 years ago terser-webpack plugin V2 will only cache to disk when using webpack 4. When used with webpack 5 it uses webpacksβ caching API and is dependent on this being set to filesystem to benefit 2nd cold builds.
I am currently experimenting with this and hoping to enable webpacksβ file system caching in the CLI in the near future.
Webpack 4, code path https://github.com/webpack-contrib/terser-webpack-plugin/blob/version-2/src/Webpack4Cache.js
Webpack 5, code path https://github.com/webpack-contrib/terser-webpack-plugin/blob/version-2/src/Webpack5Cache.js
kemsky
commented
3 years ago Is it possible to turn off caching in v11?
alan-agius4
commented
3 years ago Yeah, you can use the NG_BUILD_CACHE environment variable.
Ex: NG_BUILD_CACHE=0 ng build
joshwiens
commented
3 years ago If I don't cache my v11 builds in my big monorepo, the build times are almost identical.
tl&dr here is CLI v12 is using Webpack 5, terser-webpack-plugin isn't caching like it does in CLI v11 using Webpack v4 and it just sort of "is what it is" for the moment.
anton-white
commented
3 years ago Same increase of the build time after migrating from v11 to v12. But here we can see more than 100% of time difference.
Before:
After:
the-ult
commented
3 years ago Same here. For a pretty small project. (2 pages with a couple of components) V11 was slow.. But v12 is even slower atm.
Might be related to: https://github.com/nrwl/nx/issues/5370
kemsky
commented
3 years ago @JoostK, @alan-agius4, I removed all scss files and set NG_BUILD_CACHE=0, results are below:
v11.2.13
>".\node_modules\.bin\ng.cmd" build --prod
β Browser application bundle generation complete.
β Copying assets complete.
β Index html generation complete.
Initial Chunk Files | Names | Size
main.a383d4343fc769770869.js | main | 3.20 MB
scripts.5b3322e07a3cdcf6af69.js | scripts | 1.48 MB
polyfills-es5.66ac62d089ac586e9220.js | polyfills-es5 | 85.88 kB
runtime.76277ef9655d34c2d937.js | runtime | 1.51 kB
| Initial Total | 4.77 MB
Build at: 2021-05-16T12:08:41.073Z - Hash: 6acba3c73318a8cd5749 - Time: 159782msv12.0.0
>".\node_modules\.bin\ng.cmd" build --prod
Option "--prod" is deprecated: Use "--configuration production" instead.
Warning: Support was requested for IE 11 in the project's browserslist configuration. IE 11 support is deprecated since Angular v12.
For more information, see https://angular.io/guide/browser-support
β Browser application bundle generation complete.
β Copying assets complete.
β Index html generation complete.
Initial Chunk Files | Names | Size
main.1bd8f29d9fb0ec7900b5.js | main | 3.22 MB
scripts.5b3322e07a3cdcf6af69.js | scripts | 1.48 MB
polyfills-es5.b787b17c5e8d81a4b18e.js | polyfills-es5 | 90.75 kB
runtime.bf3db8034d6e10a74a56.js | runtime | 1.20 kB
| Initial Total | 4.79 MB
Build at: 2021-05-16T12:02:59.182Z - Hash: a899c8b10f7d6415a015 - Time: 163759msAfter several runs +/- the same time.
Styles processing is slightly slower on v12.
mebibou
commented
3 years ago Same here, taking ~26s to compile every time I change 1 line of code whereas before in v11 it used to take only 5-10s max.
I might revert the upgrade in the meantime, its making coding a pain
JoostK
commented
3 years ago @mebibou That sounds like a different problem than the Terser cache that was being discussed above. Incremental rebuilds typically don't run production optimizations. I might have an idea of where extra time is spent (but 15-20s is more than I'd though, so may be something else at play) and I'd love to investigate, but I'd need at least profiling sessions to do so.
JonWallsten
commented
3 years ago For me it's even worse! Build time for our example repo (available for public, but stripped of most content) is up almost 500%. Angular v11: webpack 5.37.0 compiled with 3 warnings in 12455 ms Angular v12: webpack 5.37.0 compiled with 5 warnings in 49177 ms
I replaced AngularCompilerPlugin with AngularWebpackPlugin when switching to v12.
I have not yet succeeded to build our real project since I've given up after a few minutes. But based on the time above I will probably take about 8-10 minutes. Will try it out now.
Edit: Yeah, so it seems like it's around 1000% slower! Angular v11: webpack 5.37.0 compiled with 3 warnings in 45357 ms Angular v12: webpack 5.37.0 compiled with 5 warnings in 437131 ms
JoostK
commented
3 years ago @JonWallsten Can you share that repo, as you mention it's public?
JonWallsten
commented
3 years ago @JoostK: Yeah, sorry, I forgot to make it public after I wrote that: https://github.com/JonWallsten/monorepo-new I'm building with profiling enabled in Webpack as we speak. Will paste them ASAP.
Just open an issue in the repo if something doesn't work. I just updated it from Webpack v4 to v5, so I lot had changed in out real repo that it's based on.
Profile:
assets by path assets/ 556 KiB
assets by path assets/fonts/ 535 KiB
assets by path assets/fonts/*.woff2 214 KiB 7 assets
3 assets
assets by path assets/icons/*.svg 1.56 KiB 4 assets
assets by path assets/*.png 18.2 KiB 3 assets
asset assets/images/favicon.882ede6c184b86e8dd7bb2f6bb4f2990.png 1.18 KiB [emitted] [immutable] [from: src/assets/favicon.png]
assets by path *.js 35.6 MiB
asset lib.js 22.4 MiB [emitted] (name: lib) (id hint: lib)
asset main.js 6.51 MiB [emitted] (name: main)
asset angular.js 5.13 MiB [emitted] (name: angular) (id hint: angular)
asset fontawesome.js 998 KiB [emitted] (name: fontawesome) (id hint: fortawesome)
asset vendor.js 556 KiB [emitted] (name: vendor) (id hint: vendor)
asset appentries.json 1.07 KiB [emitted] [from: src/appentries.json] [copied]
asset index.html 871 bytes [emitted]
Entrypoint main 35.6 MiB = angular.js 5.13 MiB fontawesome.js 998 KiB lib.js 22.4 MiB vendor.js 556 KiB main.js 6.51 MiB
runtime modules 3.43 KiB 7 modules
orphan modules 44 bytes [orphan] 1 module
modules by path ../../node_modules/ 5.73 MiB 690 modules
modules by path ./src/ 2.58 MiB
modules by path ./src/app/components/ 1.93 MiB 67 modules
modules by path ./src/app/common/ 531 KiB 53 modules
modules by path ./src/app/*.ts 139 KiB 4 modules
./src/main.ts 998 bytes [built] [code generated]
391788 ms (resolving: 2365 ms, restoring: 0 ms, integration: 0 ms, building: 389423 ms, storing: 0 ms)
./src/environments/environment.ts 636 bytes [built] [code generated]
391788 ms ->
71 ms (resolving: 6 ms, restoring: 0 ms, integration: 0 ms, building: 65 ms, storing: 0 ms)
modules by path ../../polyfills/ 27.6 KiB
../../polyfills/es6-es7.ts 347 bytes [built] [code generated]
391788 ms ->
66 ms (resolving: 65 ms, restoring: 0 ms, integration: 0 ms, building: 1 ms, storing: 0 ms)
../../polyfills/keyboardEvent.js 27.2 KiB [built] [code generated]
391788 ms ->
87 ms (resolving: 66 ms, restoring: 0 ms, integration: 0 ms, building: 21 ms, storing: 0 ms)
../web-lib-angular/dist/fesm2015/oas-web-lib-angular.js 376 KiB [built] [code generated]
391788 ms -> 90 ms ->
3075 ms (resolving: 2566 ms, restoring: 2 ms, integration: 0 ms, building: 507 ms, storing: 0 ms, additional resolving: 6 ms)
../web-lib-core/dist/index.js 8.39 MiB [built] [code generated]
391788 ms -> 90 ms -> 104 ms ->
0 ms (resolving: 0 ms, restoring: 0 ms, integration: 0 ms, building: 0 ms, storing: 0 ms)
../web-lib-common/dist/index.js 454 KiB [built] [code generated]
391788 ms -> 90 ms -> 3075 ms ->
0 ms (resolving: 0 ms, restoring: 0 ms, integration: 0 ms, building: 0 ms, storing: 0 ms)
LOG from webpack.Compilation.ModuleProfile
<e> | 2365 ms resolve to new modules > ./src/main.ts
<e> 8197 ms resolve to new modules
<e> | | 389423 ms build modules > ./src/main.ts
<e> | 392028 ms build modules > 147 x javascript/auto with ../../node_modules/@ngtools/webpack/src/index.js
<e> 393148 ms build modules
+ 164 hidden lines
WARNING in ../../node_modules/@angular/core/__ivy_ngcc__/fesm2015/core.js 29825:15-36
Critical dependency: the request of a dependency is an expression
@ ./src/main.ts 10:15-39
WARNING in ../../node_modules/@angular/core/__ivy_ngcc__/fesm2015/core.js 29825:15-36
System.import() is deprecated and will be removed soon. Use import() instead.
For more info visit https://webpack.js.org/guides/code-splitting/
@ ./src/main.ts 10:15-39
WARNING in ../../node_modules/@angular/core/__ivy_ngcc__/fesm2015/core.js 29837:15-102
Critical dependency: the request of a dependency is an expression
@ ./src/main.ts 10:15-39
WARNING in ../../node_modules/@angular/core/__ivy_ngcc__/fesm2015/core.js 29837:15-102
System.import() is deprecated and will be removed soon. Use import() instead.
For more info visit https://webpack.js.org/guides/code-splitting/
@ ./src/main.ts 10:15-39
WARNING in C:/Users/me/repo/oas-web/packages/web-app-edit/src/environments/environment.prod.ts is part of the TypeScript compilation but it's unused.
Add only entry points to the 'files' or 'include' properties in your tsconfig.
2 warnings have detailed information that is not shown.
Use 'stats.errorDetails: true' resp. '--stats-error-details' to show it.
webpack 5.37.0 compiled with 5 warnings in 436241 msThis started failing on hot reload rebuilding, while on ng serve.
This is what I got almost 5 times during a ~5 hours work session.
β ΄ Generating browser application bundles (phase: building)...
<--- Last few GCs --->
[58819:0x102d61000] 9811769 ms: Scavenge 2032.2 (2052.4) -> 2031.6 (2052.4) MB, 251.4 / 0.0 ms (average mu = 0.221, current mu = 0.136) allocation failure
[58819:0x102d61000] 9811787 ms: Scavenge 2032.4 (2052.4) -> 2031.7 (2052.4) MB, 14.4 / 0.0 ms (average mu = 0.221, current mu = 0.136) allocation failure
[58819:0x102d61000] 9812638 ms: Mark-sweep 2032.6 (2052.6) -> 2031.6 (2052.6) MB, 845.2 / 0.0 ms (average mu = 0.243, current mu = 0.271) allocation failure scavenge might not succeed
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 0x1009dcb79]
1: StubFrame [pc: 0x100a46574]
Security context: 0x0ceb671008d1 <JSObject>
2: /* anonymous */(aka /* anonymous */) [0xcebd79906d1] [.../node_modules/webpack/lib/NormalModuleFactory.js:1] [bytecode=0xceb9482b759 offset=0](this=0x0cebab9c04b1 <undefined>,0x0ceb3b432869 <Object map = 0xceb1a889859>,0x0ceb272e61b9 <JSFunction (sfi = 0xcebfec50c51)>)
3: /* anonymo...
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0x1011d1c65 node::Abort() (.cold.1) [/usr/local/bin/node]
2: 0x10009f919 node::Abort() [/usr/local/bin/node]
3: 0x10009fa7f node::OnFatalError(char const*, char const*) [/usr/local/bin/node]
4: 0x1001e3867 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
5: 0x1001e3807 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
6: 0x10036b995 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/bin/node]
7: 0x10036d20a v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/usr/local/bin/node]
8: 0x100369c3c v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/bin/node]
9: 0x100367a3e v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
10: 0x10037390a v8::internal::Heap::AllocateRawWithLightRetry(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
11: 0x100373991 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
12: 0x10034135a v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/local/bin/node]
13: 0x100693768 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node]
14: 0x1009dcb79 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/usr/local/bin/node]
15: 0x100a46574 Builtins_CreateFunctionContextHandler [/usr/local/bin/node]
16: 0x100962524 Builtins_InterpreterEntryTrampoline [/usr/local/bin/node]
17: 0x100962524 Builtins_InterpreterEntryTrampoline [/usr/local/bin/node]
error Command failed with signal "SIGABRT".@anton-white, please keep this issue related to rebuild times. You issue is related to https://github.com/angular/angular-cli/issues/20801
JonWallsten
commented
3 years ago @clydin: That's interesting. I really thought we where used AOT. Is there anyway I can confirm this in my output?
Is 10x longer build times something you would expect for a medium sized app with AOT compared to JIT? And is 7-8 minutes build time for ditto something you would expect?
@alxhub said this in another issue a while back: `I don't think this is an issue with Angular, actually. I ran the "build:edit" and "build:prod" tasks, and both seem to produce an Ivy application which works in the browser, no JIT mode needed."
So I'm a bit confused if we're running JIT or AOT.
I can't find an option to enable AOT in AngularCompilerPlugin. So was it even possible if JIT was default?
clydin
commented
3 years ago Sorry, I was mixing different issues. The JIT/AOT area should not actually be an issue in this case. If using the the plugins directly (outside the CLI), they should both be using AOT.
JonWallsten
commented
3 years ago I did a profile after speaking to @JoostK:
sass-dart has gone haywire.
clydin
commented
3 years ago Was also just about to comment that something to try was to remove all Sass files. But the above profile image appears to confirm the problem.
JonWallsten
commented
3 years ago @clydin Let me know if you need anything else from me.
clydin
commented
3 years ago @JonWallsten The next patch release of the CLI will include two substantial performance improvements for Sass compilation (https://github.com/angular/angular-cli/pull/20740 & https://github.com/angular/angular-cli/pull/20771) to mitigate the longer dart-sass rendering. Unfortunately, since sass-loader is being used directly, that project won't benefit. You could try to manually integrate that code into the the custom Webpack setup. However, I think the from a performance perspective trying to transition to using the CLI's build system would be ideal as it attempts to adjust the Webpack configuration and compilation in a variety of ways to optimize performance.
JonWallsten
commented
3 years ago @clydin: I see. What happened to the sass implementation in Angular 12 to cause an almost 1000% (in my case) increase in build time? We use AngularCompilerPlugin (or AngularWebpackPlugin) because we have a monorepo with both Angular.JS, Angular and agnostic application as libraries of all those three kinds. I'm not sure how to incorporate Angular CLI into that mix. Especially since we also have build tools that make sure each lib is built in order and then the applications, even for rebuilds. It would probably really hard to do that with Angular CLI involved.
clydin
commented
3 years ago This material issue provides some more details regarding the performance and is most likely related to your issue (changes to both the new and legacy theming APIs occurred in v12): https://github.com/angular/components/issues/22676
Improvements for legacy theming users should also be available in the next patch release of material which don't rely on build system changes.
blyndcide
commented
3 years ago In v12 I can't even get past the initial build β Generating browser application bundles (phase: building)... phase.
gatschet
commented
3 years ago Build time is now on Windows more than 15 min with Angular 12. Before with Angular 11 it was around one minute. So, we need to go back to 11...
alan-agius4
commented
3 years ago Who is having issues please either share a reproduction or the project (even privately) or CPU profile, without any of this we cannot find the root cause of your problem, also kindly provide clear instructions to which command you are running and the relative settings in angular.json.
While I understand you might be experiencing the same problem, but by posting me too or anything along these lines without providing any meaningful information, you are not contributing to fixing the problem, but just adding no noise which makes it harder for users and contributors to find important messages which might be crucial to get to the bottom of the problem.
Back to how you can help, to generate a profile use the below steps
node --inspect-brk node_modules/@angular/cli/lib/init.js buildchrome://inspectΒ -> Open dedicated DevTools for Node -> Profiler tab ->Record (this will resume from the halted debugger in profiling mode). Wait until the process is finished and then stop recording and save the profile and upload it here.Thanks before hand.
basters
commented
3 years ago @alan-agius4 thanks for your reply and for good instructions.
I have a pretty big project and today I have upgraded it step by step from ng9 to ng12. Unfortunately I also was faced with ng12 build time issue and it works for build and for server as well.
My build time's: ng9 - ~2m ng11 - ~2m 15 sec ng12 - ~ 4m 25sec
All these benchmarks were made after npm i and it was second time builds. It means that I passed first build after npm install to give angular prepare some caches/ivy entry points and everything what can blur the picture of benchmark.
Project files were 100% same between benchmarks. Everything I did is just ng update.
Here is my angular.json files for benchmarks v9, 11, 12 and also profile files. Link to Google Drive
Hope it will help you and Angular team to find bottle neck. Feel free to ask me any additional info.
JoostK
commented
3 years ago @basters Thank you so much! I have successfully opened the v9 and v12 profile (which took several minutes to load, then several minutes to actually show up) and it appears to confirm the findings in other projects as well:
v9:
v12 (note: image does not have the same scale as the v9 screenshot!)
That orange/yellow-ish in the centre is dart-sass, which wasn't there before.
JoostK
commented
3 years ago @basters It's also striking that source-map processing is taking significantly more time in v12: 44s versus 8s in v9. I don't know why this is because source-map processing hasn't changed much. It could be that something in the pipeline is producing larger source maps, such that processing them takes a lot longer.
The Babel processing on the other hand is 20% faster in v12, from 40s to 32s (the block with the gazillion colours towards 2/3 of the trace).
Looking at it further, I'm doubting if the exact same sources are being compiled? createProgram takes 17s in v9 versus 27s in v12 and type-checking went from ~10s to ~42s. I am not sure where these large differences come from.
edit: the difference in type-checking is partly explained by the fact that v12 uses TypeScript's incremental type-checking, which is more expensive as it needs to perform extra computations. However, type-checking itself is still 24s, a lot more than the 10s in v9.
basters
commented
3 years ago @JoostK Yep, I'm 100% sure that exact same sources are being compiled. Just double checked and what I can say: only ngx-toastr and ngx-cookie-service were updated to latest versions. Everything else remains the 100% same. If ngx-cookie-service & ngx-toastr can blur the picture - I can revert them to previous versions and record ng12 build profile again, just let me know.
Its important to note that those libraries were updated for ng11 build as well to ngx-toastr@13.2.1 and ngx-cookie-service@11.0.2. For ng12 build it is ngx-toastr@14.0.0 and ngx-cookie-service@12.0.0.
alan-agius4
commented
3 years ago @basters, are you using @angular/material? if so for is this referenced in SCSS?
basters
commented
3 years ago @alan-agius4 yes, I'm using @angular/material and it was updated with ng update as well as angular and it has references in SCSS. Here is a link to theme&palette setup
alan-agius4
commented
3 years ago Looking at it further, I'm doubting if the exact same sources are being compiled? createProgram takes 17s in v9 versus 27s in v12 and type-checking went from ~10s to ~42s. I am not sure where these large differences come from.
@JoostK, this is likely coming from the fact that in v9 the build was in JIT mode.
JoostK
commented
3 years ago Looking at it further, I'm doubting if the exact same sources are being compiled? createProgram takes 17s in v9 versus 27s in v12 and type-checking went from ~10s to ~42s. I am not sure where these large differences come from.
@JoostK, this is likely coming from the fact that in v9 the build was in JIT mode.
I don't think that's the case; there's Angular analysis and template type-checking in both versions, so they are both using AOT.
alan-agius4
commented
3 years ago @JoostK, you are right.
JonWallsten
commented
3 years ago I wrote a small tool that uses both sass-migrator and migrateFileContent from @angular/material/schematics/ng-update/migrations/theming-api-v12/migration to migrate all scss files to use modules instead.
Build times is now "only" increased ~15%.
the-ult
commented
3 years ago β― nx report
Node : 14.17.0
OS : darwin x64
npm : 6.14.13
@nrwl/angular : 12.3.3
@nrwl/cli : 12.3.3
@nrwl/cypress : 12.3.3
@nrwl/devkit : 12.3.3
@nrwl/eslint-plugin-nx : 12.3.3
@nrwl/express : 12.3.3
@nrwl/jest : 12.3.3
@nrwl/linter : 12.3.3
@nrwl/node : 12.3.3
@nrwl/tao : 12.3.3
@nrwl/workspace : 12.3.3
typescript : 4.2.4Using Angular Material with "sass": "1.32.13",
And using a component lib (tkp-ddm-lib) with Customised Angular Material components (NG 11 non Ivy)
It looks like it is idle for a very long time
π Bug report
Command (mark with an
x)Description
This is v11.2.13:
Verbose log (logging itself causes slowdown, unfortunately...): angular11.txt
This is v12 with yarn.lock and node_modules removed and reinstalled:
Verbose log (logging itself causes slowdown, unfortunately...): angular12.txt
We have a single small *.scss file (overriding some material colors) and it was updated by migration. The application has only one module. I tried removing scss and css from angular.json, but it is still slower than v11.
On average it is 50% slower.
Recorded profile using node 12:
https://link.nithins.me/s2Uca0Ti