2016-05-12 3 views
0

Я периодически сохраняю данные в файл (файл открывается и закрывается каждый раз), и я хочу измерить время, затраченное файловыми операциями, с использованием Stopwatch.Закрывает ли поток поток поток?

Должен ли я включить во время измерения, принятое Close()?


У нас возникли проблемы с программным обеспечением, и я подозреваю, что операции с файлами, например. занятый жесткий диск или какие-то сбои, что может вызвать задержку. Будет ли вызов Close() в этом случае вызвать задержку (блокировку) или Close() неблокирующий метод (но где-то глубоко внутри фреймворка/файла winapi сбрасывается из буферов записи и т. Д. После него)?

Или, может быть, Write() будет медленным в случае сбоев? Я не знаю, как имитировать проблему с диском, чтобы быстро проверить, что произойдет.

+1

Либо время, затраченное на закрытие файла, слишком мало, чтобы иметь значение, либо оно не является. Как вы планируете выяснить, кто из них прав, не измеряя его? –

+1

Вы не можете получить значимые измерения. Вы никогда не пишите прямо на диск, вы пишете в кеш файловой системы. Скопируйте память в память, очень быстро. Он записывается на диск лениво, долго после того, как вы закрыли файл. Это * может * ошибиться, происходит, когда кеш файловой системы заполняется до полной емкости. Либо потому, что вы слишком много пишете, либо потому, что другие программы работают, либо потому, что на компьютере недостаточно памяти или диск слишком медленный или фрагментирован. Ваш Write() будет заблокирован до освобождения места, что может занять некоторое время. Очень случайный, очень трудно предсказать. –

+0

Как только у меня был logger, настроенный на открытие/закрытие файла каждый раз, когда на него было написано сообщение, и обнаружилась очень странная проблема: в этом случае время для написания сообщения выросло пропорционально размеру файла журнала. Иногда написание всего одного сообщения занимало 0,3 секунды. Удержание FileStream сразу же сразу увеличило производительность (и время написания сообщения стало постоянным, не зависящим от размера файла). Поэтому я подозреваю, что операция Open/Close по файлу по умолчанию синхронна (я слышал, что .NET 5 имеет асинхронные аналоги). Поэтому, если вы знаете, что вам нужен этот файл и часто пишите, я рекомендую попробовать его открыть. –

ответ

-1

Во-первых, the documentation for FileStream рекомендует звонить Dispose, а не Close. Проверка опорного источника, все Close делают:

Dispose(true); 
GC.SuppressFinalize(this); 

Будет вызову Close() в этом случае вызывает задержку (блокирование) или Close() неблокирующий метод (но где-то глубоко внутри файл framework/winapi сбрасывается из буферов записи и т. д. после )?

Close звонки Dispose, который делает две вещи:

  1. Закрыть дескриптор файла.
  2. Сбросить любые ожидающие записи на диск (по умолчанию буферизуются записи).

Конечно, «Сбросить любые ожидающие записи на диск» означает, сообщите ОС, чтобы «Сбросить любые ожидающие записи на диск». Операционная система обрабатывается по-разному в зависимости от различных факторов (например, USB-накопители, как правило, записываются менее лениво, а временные файлы никогда не могут быть сброшены на диск).

+0

Не мой нисходящий сигнал, но вы не отвечаете на мой вопрос: вызывает ли 'Close' блокирует вызывающего абонента или нет (я чувствую, что вы говорите« Нет »)? Комментарий @HansPassant объясняет, что «Write» будет блокировать вызывающего абонента в случае возникновения проблем. – Sinatr

Смежные вопросы