Add batched version for several API functions.

[Titian Cernicova-Dragomir (dragomirtitian)]

While porting our internal tool to use the new GO api we found that the overhead of IPC is often the dominating cost in a API call. To improve performance we added batched versions several API we use. These have made a huge difference in the performance of our code (once we made sure to aggressively batch API calls)

[Copilot]

Pull request overview

This PR adds batched variants of several checker-related RPC/API methods to reduce IPC overhead when many small API calls are needed (notably in the native-preview client APIs).

Changes:

• Added new protocol methods + server-side handlers to execute multiple checker queries within a single request.
• Extended the native-preview sync/async Checker APIs with overloads that accept arrays for batching.
• Added sync + async test coverage validating the new batched behaviors for several checker methods.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
internal/api/session.go	Adds request routing and server-side implementations for new batched checker operations.
internal/api/proto.go	Introduces new RPC method names, unmarshaling entries, and new batched-parameter structs.
_packages/native-preview/src/api/sync/api.ts	Adds batched overloads to the sync Checker API, issuing new batched RPC requests.
_packages/native-preview/src/api/async/api.ts	Adds batched overloads to the async Checker API, issuing new batched RPC requests.
_packages/native-preview/test/sync/api.test.ts	Adds sync tests validating the new batched checker API behaviors.
_packages/native-preview/test/async/api.test.ts	Adds async tests validating the new batched checker API behaviors.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

[Wesley Wigham (weswigham)]

Rather than individually adding bespoke batching to every API, why not add a new MethodGetBatchedRequestResults API message that takes a list of any other API queries/params and returns a list of API results for them? Then, in theory, we could set up some kind of transaction-like auto-batching on the JS side (eg, refrain from actually sending anything until the next setImmediate tick after an async call where we can automatically send over all messages queued up in a single batch).

[Titian Cernicova-Dragomir (dragomirtitian)]

Rather than individually adding bespoke batching to every API, why not add a new MethodGetBatchedRequestResults API message that takes a list of any other API queries/params and returns a list of API results for them? Then, in theory, we could set up some kind of transaction-like auto-batching on the JS side (eg, refrain from actually sending anything until the next setImmediate tick after an async call where we can automatically send over all messages queued up in a single batch).

Sure. That would definitely be a good idea. I was just following the existing pattern. I do wonder if the bespoke version can do some things better. For example for emit I am sure there is an advantage to doing multiple files at once since you don't get global errors for each.

To your point of waiting until the next tick, that only works for the async api. We are actually using the sync one so some other way to flush the transaction would be needed.

We have our own batching library that batches request automatically by API method. This solution has worked well for us in terms of performance so we are content with the current model too.

[Wesley Wigham (weswigham)]

For example for emit I am sure there is an advantage to doing multiple files at once since you don't get global errors for each.

As long as we only set up a single checker/LS instance for the whole batch, all that diagnostic stuff'll be cached, so you shouldn't see any benefit from a bespoke entrypoint.

[Ryan Cavanaugh (RyanCavanaugh)]

Thank you for contributing to the TypeScript native port!

Development has moved from this repository back to the main microsoft/TypeScript repository. GitHub does not have PR transfer functionality, so we're closing this PR here.

If this change is still relevant, please reopen it as a new pull request in microsoft/TypeScript. We'd appreciate your help carrying the contribution over, and we apologize for the extra work.

See microsoft/typescript-go#4918 for more information about the move.