Question

我正在尝试编写一些适用于Linux和Win32的代码。我发现它们之间最显着的差异（在我的代码中）是fopen()的性能。
以下代码在我的Ubuntu上需要5秒，而相同的代码在Windows XP上需要超过100秒。我想在这里做一个说明，ubuntu是VM，而XP是在真机上。

    time_t start = time(NULL);
    for(int i=0; i < 100000; ++i){
        FILE *fp = fopen("a.txt", "a");
        if (fp != NULL)
        {
            fprintf(fp, "Hello World");
            fclose(fp);
        }
    }
    time_t end = time(NULL);

    printf("\n It took %d seconds \n", end-start);

显然fopen()是造成这种差异的原因。我想知道为什么会有这么大的差异？

Answer 1

显然fopen（）就是这个原因差

不，它更可能是文件系统刷新。
在你编写的一个系统上，或者更有可能调用fclose（）时，它会阻塞，直到字节在物理上位于磁盘上（或者至少直到磁盘显示它们为止） - 另一方面文件系统立即返回，即使苍蝇是还在写

Answer 2

您使用病毒扫描程序吗？如果是，请先禁用它！

Windows上的一些API调用速度较慢。例如。你的C：\将首先翻译成/ harddrive / something（只是一个例子）。

Answer 3

除了这里使用的API之外，还有很多其他内容。

您正在文件系统上打开文件因此，正在使用的文件系统类型将影响时间，以及实现文件系统的设备的硬件速度。你没有考虑太多因素，你可以准确地说X是慢速的罪魁祸首。

Answer 4

如果您使用的是Visual C ++，请注意默认情况下stdio现在使用互斥锁来启用安全多线程。可以使用#define _CRT_DISABLE_PERFCRIT_LOCKS关闭这些内容。 [编辑31/12/2013] ~~我不确定，但我认为Linux stdio实现通常会假设单线程行为，所以不要有这种锁定开销。~~ Linux stdio实现同样遵守需要安全多线程的POSIX和C11标准，提供名称以_unlocked结尾的无锁版本的函数，例如fgetc_unlocked()。

此处有更多信息：http://msdn.microsoft.com/en-us/library/ms235505%28v=VS.80%29.aspx

Answer 5

这不相关。这不是I / O功能的正常使用方案，因此不必针对此情况进行优化。也许windows使用同步flush（）而linux使用asyncronous。

Answer 6

我会做以下事情：

在类似于预期目标的真实硬件机器上试用
在Windows和Linux测试中使用相同的计算机 - 双启动或其他。
禁用Windows框中的所有第三方加载项，尤其是AV软件（注意：如果您的公司IT部门不允许这样做，请向他们解释这是一个软件开发实验室机器，不需要遵守他们的政策如果适当地与主要办公室网络分开）

他们很可能没有做同样的事情。文件系统可能是负责任的。要么win32框正在进行更多的刷新 - 可能是因为由于其他任务而导致ram可用性较少 - 或者Linux框在硬件上运行，这会假装刷新并引入另一级别的缓存 - 即作弊。

您的申请需要多大程度的耐久性？如果文件绝对不能在电源故障时消失（例如邮件服务器接收邮件），那么你应该fsync（）它们。 fclose（）不保证这样做

fopen（）在win32上的表现

6 个答案: