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

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

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

@ Фредрик Калсет прав. Методы File.ReadXXX - это просто удобные оболочки для класса StreamReader.

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

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

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

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

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

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

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

Использование кэша файлов Windows

Тесты чтения файлов

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

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

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

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

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

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

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

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

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

Заботиться;