I wouldn't expect the condition to be necessary, since I believe cancellationToken already uses a time-based cache.

I’ve definitely heard advice against checking the cancellation token repeatedly, but it could have been outdated or ill-advised. I’ll do a quick perf comparison.

TS Server implements a throttled cancellation token, but a LS host could provide a less efficient implementation. I don’t know if we care about that?

I care in principle, but we'd need to review all of our usages to address that (potential) problem.

I know a lot of tree walking functions that switch on node kind select only a few container kinds to check, e.g.

        function checkExpressionWorker(node: Expression | QualifiedName, checkMode: CheckMode | undefined, forceTuple?: boolean): Type {
            const kind = node.kind;
            if (cancellationToken) {
                // Only bother checking on a few construct kinds.  We don't want to be excessively
                // hitting the cancellation token on every node we check.
                switch (kind) {
                    case SyntaxKind.ClassExpression:
                    case SyntaxKind.FunctionExpression:
                    case SyntaxKind.ArrowFunction:
                        cancellationToken.throwIfCancellationRequested();
                }
            }

In fact, I’m confident that this comment is the reason I had it in my head that I should not check the cancellation token tens of thousands of times in a row in a loop.

Fair enough