Производительность методов System.IO.ReadAllxxx/WriteAllxxx

Question

Есть ли сравнение производительности методов System.IO.File.ReadAllxxx/WriteAllxxx и классов StreamReader/StremWriter, доступных в Интернете. Как вы думаете, лучший способ (с точки зрения производительности) читать/писать текстовые файлы в .net 3.0?

Когда я проверил MSDN page of System.IO.File class, в образце кода MS использует StreamReader/StreamWriter для операций с файлами. Есть ли какая-то конкретная причина для избежания методов File.ReadAllxxx/WriteAllxxx, хотя они выглядят намного проще для понимания?

Answer 1

File.ReadAllText и аналогичные методы используют StreamReader/Writers внутри, поэтому производительность должна быть сопоставимой с тем, что вы делаете сами.

Я бы сказал, по возможности, используя методы File.XXX, он делает ваш код a) более легким для чтения b) с меньшей вероятностью содержать ошибки (в любом случае вы пишете себя).

Answer 2

@Fredrik Kalseth является правильным. Методы File.ReadXXX - это просто удобные обертки вокруг класса StreamReader.

Например вот реализация File.ReadAllText

public static string ReadAllText(string path, Encoding encoding) 
{ 
    using (StreamReader reader = new StreamReader(path, encoding)) 
    { 
     return reader.ReadToEnd(); 
    } 
} 

Answer 3

Вы, вероятно, не хотите использовать File.ReadAllxxx/WriteAllxxx если у вас есть какие-либо намерения поддерживать загрузку/сохранение очень больших файлов.

Других слов, для редактора, который вы собираетесь оставаться полезными при редактировании гигабайтного размер файлов, вы хотите, чтобы некоторые конструкции с StreamReader/StreamWriter и ищу, так что вы загружаете только часть файла, который виден.

Для чего-либо без этих (редких) требований, я бы сказал, сделайте простой маршрут и используйте File.ReadAllxxx/WriteAllxxx. Они просто используют один и тот же шаблон StreamReader/Writer, так как вы все-таки код вручную, как показывает aku.

Answer 4

Если вы не делаете что-либо, например, применяя регулярное выражение, которое является многострочным, сопоставляя текстовый файл, вы обычно хотите избежать ReadAll/WriteAll. Ведение дел в более мелких управляемых кусках почти всегда приведет к повышению производительности.

Например, чтение таблицы из базы данных и отправка ее в веб-браузер клиента выполняется в небольших наборах, которые используют характер небольших сетевых сообщений и уменьшают использование памяти компьютера обработки. Нет никаких оснований для буферизации 10 000 записей в памяти на веб-сервере и сбрасывать их все сразу. То же самое касается файловых систем. Если вы обеспокоены тем, с производительностью записи многих небольших объемов данных - например, то, что происходит в основной файловой системе для выделения места и то, что накладные расходы - вы можете найти эти статьи просветить:

Windows File Cache Usage

File Read Benchmarks

Уточнение: если вы делаете ReadAll, за которым следует String.Split ('\ r'), чтобы получить массив всех строк в файле, а также использовать цикл for для обработки каждой строки, которая, как правило, приводят к худшей производительности, чем чтение файла по строкам и выполнение вашего процесса в каждой строке. Это не является жестким правилом - если у вас есть некоторая обработка, которая занимает большой кусок времени, часто лучше освобождать системные ресурсы (дескриптор файла) раньше, чем позже.Однако в отношении написания файлов почти всегда лучше удалять результаты любого преобразующего процесса (например, вызывать ToString() в большом списке элементов) для каждого элемента, чем буферизировать его в памяти.

Answer 5

Другие объяснили производительность, поэтому я не буду добавлять к ней, однако я добавлю, что вероятно, что образец кода MSDN был написан до .NET 2.0, когда вспомогательные методы недоступны.

Answer 6

Эта ссылка имеет контрольные отметки для чтения строк 50 + K и указывает, что потоковая программа на 40% быстрее.

http://dotnetperls.com/Content/File-Handling.aspx

Answer 7

Это MSR (Microsoft Research) документ является хорошим началом, они также документа ряда точечных инструментов, таких как, IOSpeed, FragDisk и т.д ... которые вы можете использовать и тестирование в вашем envrionment.

Существует также отчет/презентация updated, в которой вы можете прочитать о том, как максимизировать последовательный ввод-вывод. Очень интересные вещи, которые они развенчали, мифы «перемещение головы HD - это самая трудоемкая операция», они также полностью документируют свои тестовые приложения и связанные с ними конфигурации вплоть до материнской платы, контроллера рейда и практически любой надежной информации для вас, чтобы воспроизвести их Работа. Некоторые из основных моментов - это то, как сопоставлены Opteron/XEON, но затем они сравнивали их с безумным \ hype NEC Itanium (32 или 64 proc или что-то еще) для измерения. Из второй ссылки здесь вы можете найти гораздо больше ресурсов, как тестировать и оценивать высокопроизводительные scenerio и их потребности.

Некоторые из других документов MSR в этой же теме исследования включают в себя руководство по тому, где максимизировать ваши расходы (например, ОЗУ, CPU, Disk Spindals ... и т. Д.), Чтобы использовать ваши шаблоны использования ... все очень аккуратно ,

Однако некоторые из них датирован, но обычно старше-API, являются быстрее/низкоуровневыми теми, во всяком случае;)

я в настоящее время толкать сотни тысяч TPS на специально построенный сервере приложений, используя сочетание C#, C++/CLI, собственный код и растровое кэширование (rtl * bitmap).

Позаботьтесь;