Stop using #include <bits/stdc++.h>. Your compiler will thank you!

Source: Dev.to

The Old Way: The 4‑Step Compilation Process

Source Code (.cpp)

The code you write.

Preprocessing (.i)

The preprocessor scans for #include directives. When it sees #include <bits/stdc++.h>, it opens the header file, copies all of its lines, and pastes them directly into your translation unit.

Compilation (.obj / .o)

The compiler translates that massive wall of text into assembly and then machine code.

Linking (.exe / .out)

The linker stitches the object files together and resolves references to the actual logic stored in the standard library.

Note: .exe is the typical executable on Windows; .out (or just a binary without extension) is common on macOS/Linux.

Why #include <bits/stdc++.h> Is Problematic

• bits/stdc++.h pulls in hundreds of headers.
• For a project with, say, 50 source files, the preprocessor copies the same tens of thousands of lines 50 times.
• Even a simple #include <bits/stdc++.h> drags in sub‑headers like <iostream>, <vector>, and <algorithm>, inflating the amount of text the compiler must parse.

Impact on Execution, Binary Size, and Compilation Time

The Modern Way: C++20/23 Modules

Instead of the traditional #include chain, you can write:

import std;   // Replaces all traditional headers like <iostream>, <vector>, <algorithm>, …

Example

import std;

int main() {
    std::vector<int> prices = {4500, 1200, 8900, 2300};

    std::ranges::sort(prices);

    std::cout << "Sorted prices\n";
}

• Modules (Memory Mapping): The first import loads the binary module into RAM via mmap. Subsequent imports map the same memory region, avoiding repeated disk access.

Verdict

• #include <bits/stdc++.h> does not affect runtime performance or binary size, and the extra compilation time is often only a few seconds for small programs.
• For large‑scale projects, the cost becomes noticeable. Prefer selective, explicit headers, or better yet, adopt C++20/23 modules to keep your builds fast and your codebase clean.