Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ivy runtime performance #25569

Closed
matthewjh opened this issue Aug 19, 2018 · 7 comments
Closed

Ivy runtime performance #25569

matthewjh opened this issue Aug 19, 2018 · 7 comments
Milestone

Comments

@matthewjh
Copy link
Contributor

matthewjh commented Aug 19, 2018

What is the expected effect of the Ivy renderer on runtime performance, excluding gains from reduced bundle sizes?

I can see how ideas like breaking the renderer into atomic functions directly called by templates and locality improve bundle size and build times; it's much harder for me to see how that would help runtime performance. It seems that things like whole-program analysis and encoding directive information into consuming templates would improve runtime performance (surely why Angular did them in the first place), and that removing them would be detrimental from that perspective.

Curious to get your thoughts @mhevery

@hiepxanh
Copy link
Contributor

I have the same question

@ngbot ngbot bot added this to the needsTriage milestone Aug 20, 2018
@trotyl
Copy link
Contributor

trotyl commented Aug 21, 2018

image

7% slower won't be a big problem compared to the benefits.

@matthewjh
Copy link
Contributor Author

@trotyl yes, I know and I agree.

However, I'm curious to hear from the angular team because I'm not intimately familiar with Ivy, and there may be changes I'm unaware of that in fact improve the runtime performance beyond that from the smaller bundles.

@pkozlowski-opensource
Copy link
Member

@matthewjh excited to see all the community interest around ivy! Regarding your question about runtime performance - it is really too early to speculate. In fact it is seldom a good idea to speculate - we need hard numbers.

From our initial testing it seems like we might be faster as compared to the current view on our large tree / large table benchmarks. But we should wait with any meaningful comparisons till:

  • all the functionality is covered;
  • all the in-flight / perf-oriented refactorings land;
  • we go through a cycle of perf measuring / tunning.

Before the above happens all is just speculation. We need to ask you for more patience till we've got work completed and can share meaningful numbers.

But yeh, generally speaking we aim at having ivy at least as fast as the current view engine. Only time will tell how good we've managed.

Closing as there is nothing actionable here for now.

@mlc-mlapis
Copy link
Contributor

... isn't it the right time to publish some design docs for Ivy? All outside the core time has no real information about the basic build stones and what are the principal game rules. Re-engineering the source code and guess what was on the beginning is really wasting of expensive time.

@matthewjh
Copy link
Contributor Author

thanks @pkozlowski-opensource! Everything you said makes good sense. Looking forward to seeing numbers (including bundle size reduction!) and using Ivy.

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants