Why would code performance be better in VSCode? - c++

Question

I use g++ 12.2.0 (MinGW-w64 via MSYS2) and experience odd performance behavior when running the same code from VSCode (with Code Runner extension) and from the command line. For both, the command used is g++ f1.cpp -o f1 && f1.
For example purposes, given this code:
#include <iostream>
#include <chrono>
#include <string.h>
using
std::chrono::high_resolution_clock,
std::chrono::duration_cast,
std::chrono::nanoseconds;
void timeit(void (*func)(std::string), std::string message){
auto time_start = high_resolution_clock::now();
func(message);
auto time_end = high_resolution_clock::now();
auto duration = duration_cast<nanoseconds>(time_end - time_start).count();
std::cout << "Execution Time: " << duration * 1e-6f << " [ms]" << std::endl;
}
void run(std::string message){
std::cout << message.c_str() << std::endl;
}
int main() {
for (size_t i = 0; i < 100; i++)
timeit(&run, std::to_string(i));
}
VSCode Output:
...
96
Execution Time: 0.0025 [ms]
97
Execution Time: 0.0022 [ms]
98
Execution Time: 0.0034 [ms]
99
Execution Time: 0.0029 [ms]
Command Line Output:
...
96
Execution Time: 0.5091 [ms]
97
Execution Time: 0.5168 [ms]
98
Execution Time: 2.4943 [ms]
99
Execution Time: 0.7385 [ms]
The performance is significantly different as seen above.
It is also consistent on PowerShell and even the VSCode terminal itself.
I searched Stack Overflow and other sources for the best of my capability and yet left clueless.
Edit 1: I already tried running it with optimizations and up to 1e6 iterations and the issue still persists.
Edit 2: teapot418's answer was precise. It really was limited by the performance of the terminal and replacing std::endl with \n made a big difference in performance. Replacing the print operation with a different (and even more computationally heavy) operation showed equal performance. Colonel Thirty Two's answer raised an important point too which I should have clarified beforehand. Issue solved.

Answer 1

You are benchmarking the time of your run function, which is a single std::cout statement. Measuring I/O times of a single output line is going to have a lot of variance and depend on where stdout is getting routed to.
My psychic powers suggest that VSCode is re-routing stdout to its own output window which has a lot more buffering and performance than the default console window. And I'm guessing your console window is running under some sort of bash/unix emulation on Windows. (Or is this Linux?)
Some things to try:
You can try increasing the buffer size of the Windows console (or the console app you are using to host mingw)
Redirect to /dev/null or nul: on Windows. (e.g. f1 > /dev/null or f1 > nul:). Of course, you won't see the output, but you could change your Execution Time statement to be sent to cerr while cout is still used in the run function. But then again, I'm not sure what you are measuring.
Try compiling with -O2 optimizations. That might nullify the difference.
Try running your compiled program in a default console window instead of the Bash/Mingw/Cygin thing it might be running in now. You could try running it in powershell too.