Метод чтения StreamReader не читает указанное число символов

Я должен разобрать большой файл, так что вместо того, чтобы делать:

 string unparsedFile = myStreamReader.ReadToEnd(); // takes 4 seconds
 parse(unparsedFile); // takes another 4 seconds

Я хочу воспользоваться преимуществами первых 4 секунд и попытаться сделать обе вещи одновременно, выполнив что-то вроде:

        while (true)
        {
            char[] buffer = new char[1024];

            var charsRead = sr.Read(buffer, 0, buffer.Length);

            if (charsRead < 1)
                break;

            if (charsRead != 1024)
            {
                Console.Write("Here");  // debuger stops here several times why?
            }

            addChunkToQueue(buffer); 
        }

вот изображение отладчика :( я добавилint counter чтобы показать на какой итерации мы читаем менее 1024 байта)

enter image description here

Обратите внимание, что там, где читается 643 символа, а не 1024. На следующей итерации я получаю:

enter image description here

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

So my question is  Почему я буду читать "Случайно"? количество символов, как я повторяю бросить цикл while?

Edit

Я не знаю, с каким потоком я имею дело. Я выполняю процесс как:

        ProcessStartInfo psi = new ProcessStartInfo("someExe.exe")
        {
            RedirectStandardError = true,
            RedirectStandardOutput = true,
            UseShellExecute = false,
            CreateNoWindow = true,
        };

        // execute command and return ouput of command
        using (var proc = new Process())
        {
            proc.StartInfo = psi;
            proc.Start();                               

            var output = proc.StandardOutput;  //  <------------- this is where I get the strem

            //if (string.IsNullOrEmpty(output))
            //output = proc.StandardError.ReadToEnd();

            return output;
        }
    }
 James Black02 июл. 2012 г., 21:00
Предполагать, что он всегда будет заполнен - плохое дизайнерское решение. Если возможно, что он не будет заполнен, тогда предположим, что он не будет заполнен, и кодируйте соответственно.

Ответы на вопрос(3)

Во-первых, вы читаетеcharactersнеbytes, Это огромная разница.

Что касается того, почему он не обязательно читает все сразу: может быть, не так много доступных данных, иStreamReader решил дать вам то, что у него есть, а не блокировать на неопределенное время для заполнения вашего буфера. Это полностью зависит от его прав.

Это происходит из локального файла или по сети? Обычно локальные файловые операции гораздо чаще заполняют буфер, чем сетевые загрузки, но в любом случае вы просто не должны полагаться на заполненный буфер. Если это & quot; файл & quot; (то есть читать, используяFileStream) но это происходит из-за общего сетевого ресурса ... ну, в моем понимании это серая область :) Это поток - относитесь к этому так.

Решение Вопроса

Из документов:http://msdn.microsoft.com/en-us/library/9kstw824

When using the Read method, it is more efficient to use a buffer that is the same size as the internal buffer of the stream, where the internal buffer is set to your desired block size, and to always read less than the block size. If the size of the internal buffer was unspecified when the stream was constructed, its default size is 4 kilobytes (4096 bytes). If you manipulate the position of the underlying stream after reading data into the buffer, the position of the underlying stream might not match the position of the internal buffer. To reset the internal buffer, call the DiscardBufferedData method; however, this method slows performance and should be called only when absolutely necessary.

Так что для возвращаемого значения, документы говорят:

The number of characters that have been read, or 0 if at the end of > the stream and no data was read. The number will be less than or equal to the count parameter, depending on whether the data is available within the stream.

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

 Tono Nam02 июл. 2012 г., 21:11
Как мне получить внутренний буфер потока? Это не поток файлов и не сетевой поток. Я буду помещать, какой тип потока это на редактирование в ближайшее время ...
 02 июл. 2012 г., 21:30
Я не уверен, что вам нужно искать это. Текущее поведение потока абсолютно нормально. Вы хотите добиться лучшей производительности или чего-то еще? Внутренний буфер заполняется из сети, поэтому, если вы получаете какую-либо задержку - это сетевая задержка, и ничего общего с размерами буфера. Копия из буфера в буфер производится в памяти. Что бы вы ни делали для синхронизации размеров буфера - выигрыш в производительности от этого незначителен для сетевых задержек.

Это зависит от фактического потока, который вы читаете. Если это поток файлов, я думаю, что он вряд ли получит «частичный» данные. Однако, если вы читаете из сетевого потока, вы должны ожидать, что данные будут поступать в виде фрагментов различной длины.

Ваш ответ на вопрос