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

perf(transformer/optional-chaining): mark enter_expression as inline #7390

Conversation

Dunqing
Copy link
Member

@Dunqing Dunqing commented Nov 21, 2024

No description provided.

Copy link

graphite-app bot commented Nov 21, 2024

Your org has enabled the Graphite merge queue for merging into main

Add the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

@github-actions github-actions bot added the A-transformer Area - Transformer / Transpiler label Nov 21, 2024
Copy link
Member Author

Dunqing commented Nov 21, 2024

This stack of pull requests is managed by Graphite. Learn more about stacking.

@github-actions github-actions bot added the C-performance Category - Solution not expected to change functional behavior, only performance label Nov 21, 2024
Copy link

codspeed-hq bot commented Nov 21, 2024

CodSpeed Performance Report

Merging #7390 will not alter performance

Comparing 11-21-perf_transformer_optiona-chaining_mark_enter_expression_as_inline (e26916c) with main (9778298)

Summary

✅ 30 untouched benchmarks

Copy link
Contributor

@overlookmotel overlookmotel left a comment

Choose a reason for hiding this comment

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

I suggest to move more code out of enter_expression. To make sure enter_expression gets inlined, you want the function to be as small as possible. Only include logic which is "unless [cheap check], do nothing".

The point is that in most cases expr is not a ChainExpression or a UnaryExpression with delete operator, so want to make enter_expression as optimized as possible for the common "nothing to do here" path.

In practice, this means to move these two blocks out into separate functions:

if self.is_inside_function_parameter {
    // To insert the temp binding in the correct scope, we wrap the expression with
    // an arrow function. During the chain expression transformation, the temp binding
    // will be inserted into the arrow function's body.
    Self::wrap_arrow_function(expr, ctx)
} else {
    self.transform_chain_expression(false, expr, ctx)
}
if self.is_inside_function_parameter {
    // Same as the above explanation
    Self::wrap_arrow_function(expr, ctx)
} else {
    self.transform_chain_expression(true, &mut unary_expr.argument, ctx)
}

@Boshen Boshen changed the title perf(transformer/optiona-chaining): mark enter_expression as inline perf(transformer/optional-chaining): mark enter_expression as inline Nov 21, 2024
@Dunqing Dunqing changed the title perf(transformer/optional-chaining): mark enter_expression as inline perf(transformer/optional-chaining): mark enter_expression as inline Nov 21, 2024
@Dunqing
Copy link
Member Author

Dunqing commented Nov 21, 2024

I suggest to move more code out of enter_expression. To make sure enter_expression gets inlined, you want the function to be as small as possible. Only include logic which is "unless [cheap check], do nothing".

The point is that in most cases expr is not a ChainExpression or a UnaryExpression with delete operator, so want to make enter_expression as optimized as possible for the common "nothing to do here" path.

In practice, this means to move these two blocks out into separate functions:

if self.is_inside_function_parameter {
    // To insert the temp binding in the correct scope, we wrap the expression with
    // an arrow function. During the chain expression transformation, the temp binding
    // will be inserted into the arrow function's body.
    Self::wrap_arrow_function(expr, ctx)
} else {
    self.transform_chain_expression(false, expr, ctx)
}
if self.is_inside_function_parameter {
    // Same as the above explanation
    Self::wrap_arrow_function(expr, ctx)
} else {
    self.transform_chain_expression(true, &mut unary_expr.argument, ctx)
}

Thank you for your long explanation, I think I understand now!

@Boshen
Copy link
Member

Boshen commented Nov 21, 2024

No change 🤔 Maybe it was already inlined.

@overlookmotel
Copy link
Contributor

I'm going to try some stuff... marking as draft for now.

@overlookmotel overlookmotel marked this pull request as draft November 22, 2024 00:06
@Boshen Boshen marked this pull request as ready for review November 25, 2024 08:36
@Boshen Boshen added the 0-merge Merge with Graphite Merge Queue label Nov 25, 2024
Copy link
Member

Boshen commented Nov 25, 2024

Merge activity

  • Nov 25, 3:36 AM EST: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
  • Nov 25, 3:36 AM EST: A user added this pull request to the Graphite merge queue.
  • Nov 25, 9:05 AM UTC: The Graphite merge queue couldn't merge this PR because it timed out.
  • Nov 25, 4:05 AM EST: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
  • Nov 25, 9:05 AM UTC: The merge label '0-merge' was removed. This PR will no longer be merged by the Graphite merge queue
  • Nov 25, 5:40 AM EST: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
  • Nov 25, 5:40 AM EST: A user added this pull request to the Graphite merge queue.
  • Nov 25, 5:41 AM EST: A user merged this pull request with the Graphite merge queue.

@Boshen Boshen force-pushed the 11-21-perf_transformer_optiona-chaining_mark_enter_expression_as_inline branch from 01a2270 to 0bc763f Compare November 25, 2024 08:45
@Boshen Boshen force-pushed the 11-21-perf_transformer_optiona-chaining_mark_enter_expression_as_inline branch from 0bc763f to 528b2f4 Compare November 25, 2024 08:50
@Boshen Boshen force-pushed the 11-21-perf_transformer_optiona-chaining_mark_enter_expression_as_inline branch from 528b2f4 to 679a56a Compare November 25, 2024 08:53
@graphite-app graphite-app bot removed the 0-merge Merge with Graphite Merge Queue label Nov 25, 2024
@Boshen Boshen force-pushed the 11-21-perf_transformer_optiona-chaining_mark_enter_expression_as_inline branch from 679a56a to e26916c Compare November 25, 2024 10:31
@overlookmotel overlookmotel added the 0-merge Merge with Graphite Merge Queue label Nov 25, 2024
@graphite-app graphite-app bot merged commit e26916c into main Nov 25, 2024
26 checks passed
@graphite-app graphite-app bot deleted the 11-21-perf_transformer_optiona-chaining_mark_enter_expression_as_inline branch November 25, 2024 10:41
@overlookmotel
Copy link
Contributor

No change in benchmarks. But I still think this change is good. The smaller we can make all enter_expression / exit_expression methods, the more likely enter_expression / exit_expression in other transforms can be inlined too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0-merge Merge with Graphite Merge Queue A-transformer Area - Transformer / Transpiler C-performance Category - Solution not expected to change functional behavior, only performance
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants