Производительность fopen () на win32

Question

Я пытаюсь написать код, который работает как на Linux, так и на Win32. Самое заметное различие, которое я нахожу между ними (в моем коде), это производительность fopen().
Следующий код занимает 5 секунд в моей Ubuntu, и тот же код занимает более 100 секунд в Windows XP. Я хотел бы отметить, что 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

Вы пользуетесь антивирусом? Если да, сначала отключите его!

И некоторые вызовы API медленнее в Windows. НАПРИМЕР. ваш C: \ будет сначала переведен в / harddrive / что-то (просто пример).

Answer 3

Если вы используете 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 4

Здесь гораздо больше, чем просто используемый API.

Вы открываете файл в файловой системе.
Таким образом, тип используемой файловой системы будет влиять на время, а также скорость аппаратного обеспечения устройств, реализующих файловую систему. Существует слишком много факторов, которые вы не принимаете во внимание, и вы можете точно сказать, что X является виновником медленных скоростей.

Answer 5

Это не актуально. Это не обычный сценарий использования функций ввода / вывода, поэтому их не нужно оптимизировать для этого случая. Возможно, в Windows используется синхронный flush (), а в Linux используется асинхронный.

Answer 6

Я бы сделал следующее:

1. Попробуйте на реальной аппаратной машине, аналогичной спецификации намеченной цели
2. Используйте один и тот же компьютер в тестах Windows и Linux - двойная загрузка или что-то в этом роде.
3. Отключите все сторонние надстройки на Windows, особенно программное обеспечение AV (примечание: если ИТ-отдел вашей компании не разрешает этого, объясните им, что это компьютерная лаборатория для разработки программного обеспечения, и на него не нужно распространять свою политику если подходящим образом отделен от сети основного офиса)

По всей вероятности, они не делают одно и то же. Файловая система, вероятно, несет ответственность. Либо блок win32 выполняет намного большую очистку - возможно, из-за того, что у него меньше оперативной памяти из-за других задач - либо блок Linux работает на оборудовании, которое подделывает сброс и вводит другой уровень кэширования - то есть читы.

Какой уровень прочности требуется в вашем приложении? Если файлы абсолютно не должны исчезать при сбое питания (например, почтовый сервер, получающий почту), вам следует использовать fsync (). fclose () не гарантирует этого