-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Allow cancellation during extract method's symbol walking #18121
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
Conversation
@amcasey, |
src/compiler/symbolWalker.ts
Outdated
@@ -158,6 +162,10 @@ namespace ts { | |||
} | |||
|
|||
function visitSymbol(symbol: Symbol): boolean { | |||
if (cancellationToken) { |
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 have 2 fairly ignorant questions
- Are cancellation checks expensive (I seem to recall that it's based on checking a named pipe, which sounds scary)? Is it throttled?
- How many times do we expect
visitSymbol
to be called in a "typical" operation?
I guess the overall question I'm asking is whether you're fairly sure this check isn't a performance burden.
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.
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.
FYI: Some crude overhead measurements from back when I prototyped this: https://github.com/billti/cancellation#overhead . Definitely use the throttling mechanism. We've seen significant perf regressions when this wasn't done in prior cancellation checks.
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.
As Vlad said, cancellation checks are throttled. Having said that, I don't have a sense of how expensive cancellability is.
@@ -932,7 +933,8 @@ namespace ts.refactor.extractMethod { | |||
scopes: Scope[], | |||
enclosingTextRange: TextRange, | |||
sourceFile: SourceFile, | |||
checker: TypeChecker) { | |||
checker: TypeChecker, | |||
cancellationToken: CancellationToken) { |
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.
With the other changes, I don't think this argument is used anywhere anymore.
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 you mean cancellationToken
, I believe it is closed over in the accept lambda below.
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.
@amcasey Ack, sorry, thought I was reading a different file here. Nevermind. All good.
Per @weswigham's suggestion, handle cancellation in the Accept predicate, rather than adding a new SymbolWalker API. |
@@ -932,7 +933,8 @@ namespace ts.refactor.extractMethod { | |||
scopes: Scope[], | |||
enclosingTextRange: TextRange, | |||
sourceFile: SourceFile, | |||
checker: TypeChecker) { | |||
checker: TypeChecker, | |||
cancellationToken: CancellationToken) { |
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.
@amcasey Ack, sorry, thought I was reading a different file here. Nevermind. All good.
Allow cancellation during extract method's symbol walking
...since it's potentially expensive.