-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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(cdk/table): Use afterRender hooks #28354
Conversation
9a6d0c4
to
0235c85
Compare
0235c85
to
d5f5cc1
Compare
568ccea
to
77491f4
Compare
private readonly _writeTasks: (() => unknown)[] = []; | ||
private readonly _readTasks: (() => unknown)[] = []; | ||
|
||
constructor(private readonly _ngZone: NgZone) { |
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.
AFAIK afterRender
has its own internal coalescing mechanism. Couldn't we switch to using afterRender
directly in the table and remove the _CoalescedStyleScheduler
altogether?
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.
Not really possible alas as afterRender has a few limitations.
- It can only be invoked during injection context, wheras I need to have things happen at arbitrary times, and to be re-entrant.
- afterRender has no mechanism to flush outside of NgZone/CD, which is needed sometimes in the table.
- I tried to move columnResize off of the old _CoalescedStyleScheduler hooks, but could not get that to work, so is a blocker for now at least.
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.
It can only be invoked during injection context, wheras I need to have things happen at arbitrary times, and to be re-entrant.
This shouldn't be an issue because you can pass an injector instance to afterRender
.
afterRender has no mechanism to flush outside of NgZone/CD, which is needed sometimes in the table.
Is there any reason to not just trigger applicationRef.tick
imperatively in these cases?
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.
applicationRef.tick has additional side effects performance-wise. Given there are no changes to application state, just CSS, that does not seem like the best choice here.
Also, question on afterRender() - can you call safely afterRender/afterNextRender during afterRender? There are cases where it needs to do that.
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.
If/when you get to trying to submit this change again, I'd love to discuss this more. afterRender
is still in developer preview and its behavior is being tuned to ensure it satisfies required use-cases.
afterRender has no mechanism to flush outside of NgZone/CD, which is needed sometimes in the table.
...
applicationRef.tick has additional side effects performance-wise. Given there are no changes to application state, just CSS, that does not seem like the best choice here.
...
Given there are no changes to application state, just CSS, that does not seem like the best choice here.
We're working on several things that can help address this:
- Guaranteeing that render hooks run, even when no change detection is scheduled: angular/angular@80b953a
- Not refreshing views if we only need to flush
afterRender
hooks: angular/angular@51dfdbb - Things that notify the scheduler (like
afterRender
hooks) should work when outside the zone (even in applications that use ZoneJS): signal updates andmarkForCheck
should always schedule change detection angular#53844
77491f4
to
420b433
Compare
(cherry picked from commit 81cb5ac)
This reverts commit 81cb5ac.
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. |
Per Chrome devtools, in the Angular Material devapp, cuts down startup rendering time by about 60ms (~25%). In a real app screen with a single large table, the reduction is ~16%. The main difference is that the change makes a bigger difference when multiple tables are rendering at the same time, since previously separate CoalescedStyleScheduler instances would be grouping tasks separately per-table. Seems to reduce scripting time a smidge as well.