RC.5 - RC.7 performance

[kemsky]

I'm submitting a ... (check one with "x")

[x] bug report => search github for a similar issue or PR before submitting

Current behavior
After migration to RC.5-7 there is significant delay ~2.5 seconds:

Reproduction of the problem
Before RC.5 i used component directives property, application did not have any noticeable delays, but directives was removed.
As a quick solution i have moved components to module, it is single module application currently. It looks like all module components are compiled at startup, which can not be fast. Templates and styles are inlined using webpack.

I wonder if splitting code into sub-modules help?

• Angular version: 2.0.0-rc.5-7
• Browser: [all ]
• Language: [TypeScript 1.8]

[robwormald]

This is an architectural change to align with Ahead of Time compilation - all components are compiled before the app bootstraps. This compilation step moves to the build step (and not in the browser) so it becomes a non-issue. Look for docs on AoT compilation in the next couple of days, or check out www.syntaxsuccess.com/viewarticle/ahead-of-time-compilation-in-angular-2.0 or http://blog.mgechev.com/2016/08/14/ahead-of-time-compilation-angular-offline-precompilation/ till then.

[kemsky]

Is there anything that i can do except switching to AOT?

AOT is not something i can get for free: it has issues with inheritance, public/private fields, custom decorators, performance #11458 - was perfectly valid issue and many others.

[yuanfeiz]

What's the status of AoT, is it stable enough to turn to?

[IgorMinar]

@kemsky you can split your application into multiple NgModules and lazy load them via router.
@yuanfeiz yes, we recommend the AoT over JiT for bigger production apps.

[kylecordes]

@IgorMinar There was some discussion in the Gitter channel and I think in another issue here a while back, about how AOT yields a much larger size than shipping the compiler plus the templates, for a very large application; I think that we may find that very large applications intentionally choose to AOT just the shell to launch fast, and then JIT the rest for a smaller total file transfer. I realize this may won't match the vision of the architecture, just raising it as a possibility that may emerge as an enterprise practice.

[kylecordes]

(Though personally I am really excited about AOT and will encourage everyone to use it exclusively.)

[yuanfeiz]

@kylecordes I haven't tried AoT, after reading some blogs I have the idea that it enables tree-shaking. If that's the case, there should be a balance between the size of the striped-out code and the compiled code, isn't it?

[kylecordes]

@yuanfeiz Yes:

AOT'ed template output is much bigger than the template "source".

But AOT let's you skip the compiler for web deployment (and it is a pretty large chunk of A2 total size) and it enables tree shaking.

Net result:

• Small things: AOT will yield a much smaller deployable. And faster start time.
• Medium-size things: AOT will yield about the same size deployable, faster start time.
• Big things: AOT will yield a significantly larger deployable; if the network is really fast this may still yield a faster start time though.

I expect will be many more words spilled about this trade-off over the coming months.

[yuanfeiz]

Cool, is there any clear boundary regarding the size? My project has several hundreds of very small files(<3KB), is the total size matters or the file counts?

Also how much do uglify and compression reduce for the AoT'ed assets?

Thanks!

[kylecordes]

I doubt there will be a general answer that puts numbers on it. Just test it on your app each way. If you are "doing it right", your app won't have more than a couple lines of code different to wire things up for JIT or AOT.

[yuanfeiz]

OK, got it thanks.

[zoechi]

@kylecordes Isn't lazy loading a better option than using JIT on parts of the app for fast startup?

I also wouldn't take the current results too seriously. The Angular team is still working on ironing out issues on their first attempt. I'm sure there is still room for further improvement to be done after release.

[kemsky]

I've managed to reduce delay using style and template minification. It is around 2 seconds now.

I believe lazy loading makes sense mostly for large modules and large means they have big size in megabytes or bandwidth is low. In this case performance problem has nothing to do with size or bandwidth. Lazy loading would simply split 2 second delay into noticeable delays (network latency, server response time) all over the app.

I think i know right direction: webpack provides option to load module, but not execute, eliminating loading delays, i hope someone could help to put it together :)

AOT benefits tend to reduce when amount of components grows, i hope one day i could compare numbers.

[kylecordes]

@zoechi Yes, and I already had that in mind in my comment earlier.

My hope and plan is that even for large application (composed of various lazy loaded modules), the benefit of AOT are big enough to use it all the way across an application even though the total size is larger. My guess is that things will be more complex in the real world as they so often are, and some big project will weigh the tradeoffs and not use AOT 100% of the time.

[vicb]

Closing this issue. Scream if you don't agree.

[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.}