Boost the output speed of Windows Terminal.

[nnpyro1]

Description of the new feature

I've developed a program that needs to output roughly 84 bytes of data within 1ms. This demand can be fulfilled on terminals like Alacritty, but with Windows Terminal, it considerably hampers the program's performance. Hence, I've raised this issue in hopes of making Windows Terminal's output a bit speedier.

Proposed technical implementation details

I believe that upon receiving output information, it ought not to be rendered immediately; instead, it should be directly placed into the buffer, and the text should subsequently be rendered onto the screen during idle periods.

[zadjii-msft]

I'm guessing there's something weird in the way you're writing the output in your application. Terminal is more than capable of handling large amounts of data. Here's a PR from back in july 2023 that improved our throughput of 4KiB chunks of data from 78MB/s to 93MB/s:

#15499

there are more PRs in this release too. From the release notes for 1.19:

• The text buffer has been reorganized to be (1) faster (2) smaller (3) harder, better, etc.
  • Rows are initialized lazily in chunks of 128 or so; we no longer spend memory on blank space you'll never see (Initialize rows lazily #15524) (Stop committing the whole buffer when determining if it's empty #15582)
  • Reading, writing, initialization, etc. has been cleaned up and vectorized (Vectorize ROW initialization #15501) (Vectorize StateMachine::ProcessString #15498) with fast passes and other optimizations (Add an ASCII fast-pass to ROW #15499) (A small optimization of COOKED_READ_DATA::_erase #15879) (Move AdaptDispatch::_FillRect into TextBuffer #15541) (Reduce cost of resetting row attributes #15497)
  • We've rewritten resize with reflow so it's like a billion times faster and more correct (Reimplement TextBuffer::Reflow #15701)

[lhecker]

The problem is the static overhead per write, not the speed of processing text per se. In fact, Windows Terminal itself is so fast that writing 1 byte of text takes pretty much exactly as long as writing 4KiB of text.

It is condrv and its fully synchronous LPC backing that causes this issue. The solution is to change it to an asynchronous LPC for pure text writes. Other console APIs should result in synchronous "synchronization points", just like how they act now. This would allow two neighboring 84 byte writes to be batched together and handled asynchronously. I consider implementing this to be a high priority because it is the biggest remaining behavior difference between programming for Windows and UNIX (on UNIX, IO writes are typically async).

That said...

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

#include <cstdio>

int main() {
    static constexpr char str[] = "[2026-07-27 15:16:14:769][ Info ] ../../modules/rpepengine/rpepengine.cpp onCommunicationReadyRead 932\r\nData # 162 received.\r\n";
    const auto len = static_cast<DWORD>(sizeof(str) - 1);
    const auto handle = GetStdHandle(STD_OUTPUT_HANDLE);

    const auto previousCP = GetConsoleOutputCP();
    SetConsoleOutputCP(CP_UTF8);

    constexpr int iterations = 10000;
    DWORD written = 0;

    // Warm-up
    WriteFile(handle, str, len, &written, nullptr);

    LARGE_INTEGER freq, start, end;
    QueryPerformanceFrequency(&freq);
    QueryPerformanceCounter(&start);

    for (int i = 0; i < iterations; i++) {
        WriteFile(handle, str, len, &written, nullptr);
    }

    QueryPerformanceCounter(&end);

    SetConsoleOutputCP(previousCP);

    const double totalMs = (end.QuadPart - start.QuadPart) * 1000.0 / freq.QuadPart;
    const double perCallNs = totalMs * 1e6 / iterations;

    fprintf(stderr, "\n");
    fprintf(stderr, "Iterations : %d\n", iterations);
    fprintf(stderr, "Total      : %.4f ms\n", totalMs);
    fprintf(stderr, "Per call   : %.1f ns\n", perCallNs);
    return 0;
}

Iterations : 10000
Total      : 125.7646 ms
Per call   : 12576.5 ns

It takes 13us, not 1ms - You ARE doing something fundamentally wrong. One possible reason is using printf for logging, which is always the wrong thing to do. This is true on any OS, even if it may appear as if it was faster on Linux (it is faster, and yet printf will still be your bottleneck).

[lhecker]

As an aside, if you're writing a game, I suggest investing early in https://superluminal.eu/

[DHowett]

I believe that upon receiving output information, it ought not to be rendered immediately; instead, it should be directly placed into the buffer, and the text should subsequently be rendered onto the screen during idle periods.

This is, broadly, already true of our rendering engine... with one caveat: if we waited for idle periods, an application could deny a chance to render by simply writing out a lot of content.

Anyway. We don't render output immediately. :)

[microsoft-github-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.