4

给出以下非常简单的 for 循环：

int main (void) {
    for (int i = 0 ; i < 1000000; i++) {
         std::cout<<i<<std::endl;
    }
}

使用 Microsoft Visual Studio 2012 在干净的 Windows 8 专业版上运行此代码每 100k 打印大约需要 15 秒。

在 mac os x 上，使用同一台计算机，xcode 只需 3 秒即可输出 1 行。

我几乎 100% 确定它与性能无关，它只是与输出机制或其他东西有关。

有人可以证实这一点..吗？只是要知道我的 windows 和视觉工作室很好。

4

3 回答 3

3

这取决于外部因素。就像正在使用的终端应用程序一样。例如，在 OS X 和 Linux 上，您可以绕过终端并使用以下命令运行它：

./program > /dev/null

它在大约 0.2 秒内完成。

标准 C++ 中的 I/O 是阻塞操作。这意味着程序在等待操作系统处理输出时“冻结”。最后，如果终端应用程序不是那么快，这将导致程序被“冻结”在等待状态相当多。

于 2013-07-23T18:12:27.407 回答
2

std::endl冲洗线路。这样做非常昂贵。

试着做 ：

std::cout << i << '\n';

在大多数其他常见的交互式 I/O 场景中，std::endl 在与 std::cout 一起使用时是多余的，因为来自 std::cin 的任何输入、到 std::cerr 的输出或程序终止都会强制调用 std::cout .flush()。

某些来源鼓励使用std::endl代替'\n'可能会显着降低输出性能。

来源

编辑： 输出操作成本高昂并且取决于外部因素。这就是为什么这里很慢。例如，正在使用的终端应用程序可能是某些性能问题的因素。

您可以通过将输出重定向到/dev/null/：

./a.out > /dev/null

关于输出性能，您可以阅读：http ://codeforces.com/blog/entry/5217

于 2013-07-23T17:58:16.743 回答
1

请注意，这是我的更多猜测，但仍然：

我怀疑的是，你的小测试程序的整体运行时的差异（顺便说一句。Windows / OSX）与各自编译器生成的代码没有任何关系。

根据我在 Windows 上控制台输出的经验，我强烈怀疑这里的“瓶颈”是将字符数据从您的程序铲到 Windows 控制台和 cmd.exe 显示它。

可能只是 OSX 上的控制台/shell/bash 比 Windows 控制台更快地接受程序的输出。

您可以尝试将此程序的输出重定向到一个文件（在 CLI 上启动它时使用重定向test.exe > output.txt），看看您是否以这种方式测量任何差异。

于 2013-07-23T18:15:06.130 回答