Earlier quoted context omitted.
But what's the use case for this? When do I actually need to DISPLAY megabytes worth of output as lag-free as possible on a terminal? There is no way for the intended recipient of displayed information (aka. the user) to process any of it, so what's the point of eliminating lag?
What about when you don't know that it ends up being megabytes ? Say you're running Gradle on a large project that does a full recompilation. You don't really particularly care, you know that module X has warnings, etc. But it still prints it all out by default. With carriage returns to update the current percentage, ANSI codes and more. Any millisecond that you spend blocking on outputting your terminal is time that…
Many Build tools don't just pipe the output of every program to their own STDOUT, but redirect them to a logger, which usually runs asyncronously, so from the PoV of the compiler, its output is processed without delay.
Secondly, if I know that the build produces a huge amount of output, I redirect it to a file instead. If I don't know the first time, I interrupt, correct my command and re-build.