Batch native debug Output writes

[Sean McManus (sean-mcmanus)]

Summary

This PR is an attempt to work around VS Code running out of memory (OOM) when C_Cpp.loggingLevel is set to 7 and C/C++ generates a large volume of diagnostic output. It batches native debug Output writes to reduce per-append update pressure while preserving all localized text, line feeds, message order, logging levels, and Output-panel behavior.

This PR was investigated and created by GitHub Copilot (in VS Code). Any message starting with ✨Copilot: was sent by Copilot.

Details

• Use a 65,536 UTF-16-code-unit flush threshold and a single 50 ms timer anchored to the first buffered input. Keep oversized inputs intact and flush them synchronously.
• Flush pending native diagnostics before ordinary Output operations and before channel disposal; cancel timers cleanly, including when language-server shutdown rejects.
• Add deterministic buffer and logger tests for localization, LF behavior on both platform EOLs, ordering, size/timer flushes, reentrant writes, oversized inputs, delayed/rejected shutdown, and no duplicate flushes.

Validation

• 21 focused unit tests passed.
• Project TypeScript compile/typecheck and ESLint for all touched TypeScript files passed.
• An isolated injected-writer comparison preserved all 53,258,890 bytes from 300,000 messages while reducing append calls from 300,000 to 812 (99.73% fewer), with matching input/output SHA-256 hashes.

Scope

Batching reduces Output append frequency; it does not reduce native notification count or bound VS Code's total retained Output text. The synthetic measurement does not establish that every renderer out-of-memory scenario is eliminated.

[Copilot]

🟢 Approval recommended

The implementation is focused and thoroughly covers ordering, flushing, reentrancy, localization, and failure paths.

Pull request overview

Batches native diagnostics to reduce Output-channel append pressure while preserving output semantics and shutdown behavior.

Changes:

• Adds a threshold- and timer-based BatchedWriter.
• Integrates batching and reliable shutdown flushing.
• Adds comprehensive batching, ordering, localization, and disposal tests.

File summaries

File	Description
Extension/src/Utility/Async/batchedWriter.ts	Implements bounded batching.
Extension/src/logger.ts	Batches native diagnostic output.
Extension/src/main.ts	Ensures channels are disposed on shutdown failures.
Extension/test/unit/batchedWriter.test.ts	Tests batching edge cases.
Extension/test/unit/logger.test.ts	Tests logger integration and shutdown.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Colen Garoutte-Carson (Colengms)]

It looks like we're working around an issue in VS Code. OutputChannel.append() is fire-and-forget: no backpressure, completion signal, queue limits, or documented throughput constraints. If valid high-volume calls can build an unbounded internal queue and OOM, VS Code should coalesce/bound that work or expose a streaming/backpressure API. Rather than working around this problem ourselves, perhaps we could instead propose a fix for VS Code itself?

[Sean McManus (sean-mcmanus)]

✨Copilot: Colen Garoutte-Carson (@Colengms) Agreed that the underlying Output scalability issue belongs in VS Code. This PR is only a client-side mitigation, not an alternative to an upstream fix: it reduces append/update frequency while retaining the complete diagnostic stream, but it neither adds backpressure nor bounds the final Output model. The reported append-count reduction is from an injected writer, not a renderer OOM test. Whether to keep this as an interim mitigation or defer it in favor of an upstream fix is a maintainer decision; no upstream fix is included in this PR.

[Sean McManus (sean-mcmanus)]

It looks like we're working around an issue in VS Code. OutputChannel.append() is fire-and-forget: no backpressure, completion signal, queue limits, or documented throughput constraints. If valid high-volume calls can build an unbounded internal queue and OOM, VS Code should coalesce/bound that work or expose a streaming/backpressure API. Rather than working around this problem ourselves, perhaps we could instead propose a fix for VS Code itself?

I have a VS Code PR -- it's been un-reviewed for 6+ weeks, so I'm reluctant to submit a PR for it, but I could file an issue and see if anyone can agree to review it.