Каков наилучший размер буфера памяти для размещения файлов из Интернета?

Каков наилучший размер буфера памяти для размещения файлов из Интернета? Некоторые из образцов сказали, что это должно быть 1K. Ну, мне нужно знать вообще, почему? А также какая разница, если мы загружаем небольшой .PNG или большой .AVI?

Stream remoteStream;
Stream localStream;
WebResponse response;

try
{
    response = request.EndGetResponse(result);

    if (response == null)
        return;

    remoteStream = response.GetResponseStream();

    var localFile = Path.Combine(FileManager.GetFolderContent(), TaskResult.ContentItem.FileName);
    localStream = File.Create(localFile);

    var buffer = new byte[1024];
    int bytesRead;

    do
    {
        bytesRead = remoteStream.Read(buffer, 0, buffer.Length);
        localStream.Write(buffer, 0, bytesRead);
        BytesProcessed += bytesRead;
    } while (bytesRead > 0);
}

Ответ 1

Используйте как минимум 4 КБ. Это обычный размер страницы для Windows (то есть, гранулярность, с которой Windows сама управляет памятью), а это значит, что распределителю памяти.Net не нужно разбивать страницу 4 КБ на 1 КБ распределения.

Конечно, использование блока размером 64 КБ будет быстрее, но только незначительно.

Ответ 2

Для чего это стоит, я тестировал чтение текстового файла 1484 КБ с использованием прогрессивных мощностей двух (размеры 2,4,8,16...). Я распечатал в окне консоли количество миллисекунд, необходимых для чтения каждого из них. Многое прошлое 8192 года, похоже, не сильно отличалось. Вот результаты на моей 64-разрядной машине Windows 7.

2^1 = 2 :264.0151
2^2 = 4 :193.011
2^3 = 8 :175.01
2^4 = 16 :153.0088
2^5 = 32 :139.0079
2^6 = 64 :134.0077
2^7 = 128 :132.0075
2^8 = 256 :130.0075
2^9 = 512 :133.0076
2^10 = 1024 :133.0076
2^11 = 2048 :90.0051
2^12 = 4096 :69.0039
2^13 = 8192 :60.0035
2^14 = 16384 :56.0032
2^15 = 32768 :53.003
2^16 = 65536 :53.003
2^17 = 131072 :52.003
2^18 = 262144 :53.003
2^19 = 524288 :54.0031
2^20 = 1048576 :55.0031
2^21 = 2097152 :54.0031
2^22 = 4194304 :54.0031
2^23 = 8388608 :54.003
2^24 = 16777216 :55.0032

Ответ 3

2k, 4k или 8k - хороший выбор. Не важно, насколько размер страницы, изменение скорости было бы крайне незначительным и непредсказуемым.

Прежде всего, память С# может быть перемещена, С# использует сборщик сборщиков мусора. Нет никакой информации о том, где будут выделяться данные.

Во-вторых, массивы в С# могут быть образованы несмежной областью памяти! Массивы хранятся смежно в виртуальной памяти, но непрерывная виртуальная память не означает непрерывную физическую память.

В-третьих, структура данных массива в С# занимает несколько байтов больше, чем сам контент (он хранит размер массива и другую информацию). Если вы выделяете количество байтов размера страницы, использование массива будет почти всегда переключаться на страницу!

Я бы подумал, что оптимизация кода с использованием размера страницы может быть не оптимизацией.

Обычно массивы С# работают очень хорошо, но если вам действительно нужно точное распределение данных, вам нужно использовать закрепленные массивы или распределение маршала, но это замедлит сборщик мусора.

Использование распределения маршала и небезопасного кода может быть немного быстрее, но на самом деле это не стоит усилий.

Я бы сказал, что лучше просто использовать свои массивы, не слишком много думая о размере страницы. Используйте буферы 2k, 4k или 8k.

Ответ 4

У меня проблема с удаленным закрытием компьютера при использовании буфера 64 Кбайт при загрузке из iis.

Я решил проблему поднятия буфера на 2М

Ответ 5

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

В противном случае - 4096, если у вас нет причины (желательно, чтобы небольшой буфер выдавал быструю обратную связь по интерфейсу пользователя) по причинам, уже указанным.