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

refactor(ivy): access component def through tData #22771

Closed
wants to merge 1 commit into from

Conversation

kara
Copy link
Contributor

@kara kara commented Mar 14, 2018

Small PR to remove unnecessary megamorphic property accesses when creating directives and components. Now we just incur the cost on the first template pass.

@kara kara requested a review from mhevery March 14, 2018 19:27
@kara kara added action: review The PR is still awaiting reviews from at least one requested reviewer comp: ivy target: major This PR is targeted for the next major release refactoring Issue that involves refactoring or code-cleanup labels Mar 14, 2018
@mary-poppins
Copy link

You can preview 13cfafa at https://pr22771-13cfafa.ngbuilds.io/.

@mary-poppins
Copy link

You can preview e95c8cd at https://pr22771-e95c8cd.ngbuilds.io/.

@mary-poppins
Copy link

You can preview b9ea9c8 at https://pr22771-b9ea9c8.ngbuilds.io/.

const directiveType = directiveTypes[i];
const directiveDef = directiveType.ngDirectiveDef;
const directiveDef = currentView.tView.firstTemplatePass ? directiveType.ngDirectiveDef :
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same issue here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the same deal - the directiveDef is passed through to directiveCreate, which saves it on tData.

let hostComponentDef: ComponentDef<any>|null = null;
let name = nameOrComponentType as string;
if (isHostElement) {
hostComponentDef = currentView.tView.firstTemplatePass ?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not look right to me.

  • if firstTemplatePass is true than we do megamorphic read on ngComponentDef. However I don't see the value being saved.
  • if firstTemplatePass is false than we read from tData which is right, but how did the tData get hold of the ngComponentDef Was there a separate read some place else?

What I am getting at is that I think we read ngComponentDef more often than we should. (We should do it exactly once) but the fact that we are not saving the value and than it is in tData tells me that there must be a second read someplace else which places it in tData

Copy link
Contributor Author

@kara kara Mar 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The componentDef is passed through to directiveCreate, which saves it on tData. This is the only read site. directiveCreate uses the def that is passed to it directly and does not do a read.

Copy link
Contributor

@mhevery mhevery left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the confusion

@kara
Copy link
Contributor Author

kara commented Mar 15, 2018

presubmit

@kara kara added action: merge The PR is ready for merge by the caretaker and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Mar 15, 2018
@mhevery mhevery closed this in e55bf8f Mar 15, 2018
leo6104 pushed a commit to leo6104/angular that referenced this pull request Mar 25, 2018
@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
action: merge The PR is ready for merge by the caretaker cla: yes refactoring Issue that involves refactoring or code-cleanup target: major This PR is targeted for the next major release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants