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
perf(core): avoid storing LView in __ngContext__ #41358
Conversation
2d315ad
to
32733ed
Compare
7038e66
to
59a47d5
Compare
816eeef
to
c2c32e2
Compare
All of the feedback should be addressed now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes @crisbeto 👍 Just left a few comments.
One more nit: should we change the fix(core)
-> refactor(core)
or perf(core)
? It looks like this is more of an improvement vs a bug fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change will break DevTools. Exporting getLViewById
will be helpful to let our metadata collection mechanism fallback to the new approach.
83bf66c
to
186f79d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for addressing the feedback @crisbeto 👍
FYI, I'm adding the "blocked" label for now to make sure we unblock Minko (based on his comment) before merging.
c8d56c2
to
68478a4
Compare
I've pushed another change to account for the recent switch from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@crisbeto thanks for applying fixes and rebasing the PR! 👍
I've left a couple comments (mostly around the areas that might potentially have null
where we extract lView
from the context).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've addressed the latest set of feedback.
FYI presubmits went well, I'll run a global one during the weekend (to make sure there are no corner-cases that we've not reviewed/discussed) and I will share results on Monday. |
FYI, global presubmit went well too, removing the "presubmit" label. |
Currently we save a reference to an `LView` on most DOM nodes created by Angular either by saving the `LView` directly in the `__ngContext__` or by saving the `LContext` which has a reference to the `LView`. This can be a problem if the DOM node is retained in memory, because the `LView` has references to all of the child nodes of the view, as well as other internal data structures. Previously we tried to resolve the issue by clearing the `__ngContext__` when a node is removed (see #36011), but we decided not to proceeed, because it can slow down destruction due to a megamorphic write. These changes aim to address the issue while reducing the performance impact by assigning a unique ID when an `LView` is created and adding it to `__ngContext__`. All active views are tracked in a map where their unique ID is used as the key. We don't need to worry about leaks within that map, because `LView`s are an internal data structure and we have complete control over when they are created and destroyed. Fixes #41047. PR Close #41358
This is a follow-up to angular#41358 where my assumption was that `destroyLView` would be called for all views down the tree, but it turns out that it only gets called for the root and we actually call `cleanUpView` for the descendants. The result is that some views might not be removed from the registry after they're destroyed. These changes move the `unregisterLView` call into `cleanUpView` instead.
…)" This reverts commit 18b33e7.
…)" This reverts commit 18b33e7.
These changes combine angular#41358 and angular#41894. Currently we save a reference to an `LView` on most DOM nodes created by Angular either by saving the `LView` directly in the `__ngContext__` or by saving the `LContext` which has a reference to the `LView`. This can be a problem if the DOM node is retained in memory, because the `LView` has references to all of the child nodes of the view, as well as other internal data structures. Previously we tried to resolve the issue by clearing the `__ngContext__` when a node is removed (see angular#36011), but we decided not to proceeed, because it can slow down destruction due to a megamorphic write. These changes aim to address the issue while reducing the performance impact by assigning a unique ID when an `LView` is created and adding it to `__ngContext__`. All active views are tracked in a map where their unique ID is used as the key. We don't need to worry about leaks within that map, because `LView`s are an internal data structure and we have complete control over when they are created and destroyed. Fixes angular#41047.
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Currently we save a reference to an
LView
on most DOM nodes created by Angular either by saving theLView
directly in the__ngContext__
or by saving theLContext
which has a reference to theLView
. This can be a problem if the DOM node is retained in memory, because theLView
has references to all of the child nodes of the view, as well as other internal data structures.Previously we tried to resolve the issue by clearing the
__ngContext__
when a node is removed (see #36011), but we decided not to proceeed, because it can slow down destruction due to a megamorphic write.These changes aim to address the issue while reducing the performance impact by assigning a unique ID when an
LView
is created and adding it to__ngContext__
. All active views are tracked in a map where their unique ID is used as the key. We don't need to worry about leaks within that map, becauseLView
s are an internal data structure and we have complete control over when they are created and destroyed.Fixes #41047.