I have written the following C# function:
static string ReadLineCRLF(System.IO.Stream Stream, ref byte[] sharedBuffer, int bufferSize = 1024)
{
StringBuilder responseString = new StringBuilder("");
string returnString = "";
byte[] buffer = new byte[bufferSize];
bool stopreading = false;
bool firstexecution = true;
while (!stopreading)
{
int readBytes;
if (firstexecution && sharedBuffer.Length > 0)
{
readBytes = sharedBuffer.Length;
sharedBuffer.CopyTo(buffer, 0);
}
else
{
readBytes = Stream.Read(buffer, 0, bufferSize); //BLOCKING HERE
}
firstexecution = false;
if (readBytes > 0)
{
int crIndex = Array.IndexOf(buffer, (byte)13); //13 = ASCII value for a carriage return
if (crIndex > -1 && Array.IndexOf(buffer, (byte)10, crIndex + 1) == crIndex + 1) //10 = ASCII value for line feed
{
stopreading = true;
sharedBuffer = readBytes - crIndex - 2 > 0 ? ArraySlice<byte>(buffer, crIndex+2, readBytes-crIndex-2) : new byte[] { };
readBytes = crIndex;
}
if (readBytes > 0)
{
responseString.Append(System.Text.Encoding.ASCII.GetString(buffer, 0, readBytes));
}
if (stopreading)
{
returnString = responseString.ToString();
}
}
if (!stopreading && readBytes <= 0)
{
returnString = null;
stopreading = true;
sharedBuffer = new byte[] { };
}
}
return returnString;
}
This function is blocking at readBytes = Stream.Read(buffer, 0, bufferSize); according to my Stack Explorer and using up a lot of computer performance. The only thing this function should do, is reading one line from a stream which is only ended by CRLF (“\r\n”).
According to the MSDN Stream.Read returns less than the number of bytes requested if that many bytes are not currently available, or zero (0) if the end of the stream has been reached. and it should usually block and not use up CPU-performance. The implementation will block until at least one byte of data can be read, in the event that no data is available. Read returns 0 only when there is no more data in the stream and no more is expected (such as a closed socket or end of file).
So why does it – according to my CLR Stack Explorer – use up so much performance (up to 70%)? I do not see any logical mistake and I think it should wait until some bytes can be received. It also seems that this behaviour does not always occur but one or two days after the start of the application execution on a Windows server.
ADDITIONAL EXPLANATION:
As the bytes are read using chunks, it might be that too many bytes are read and stored in the buffer. Therefore I use a shared buffer, allowing it to use it again to go on reading the next line. Once a line is completely read, I remove it from the buffer.
The ArraySlice function looks like this:
public static T[] ArraySlice<T>(T[] data, int index, int length)
{
T[] result = new T[length];
Array.Copy(data, index, result, 0, length);
return result;
}
How do you know that
Readis blocking, and not just taking a while to do what it needs to?IO is expensive; I would expect fully expect that a significant amount of the time spent in this method to be inside of the
Readcall. the 70% you say sounds about right. You don’t appear to be misusing the method, so the higher the percentage of time spent reading is really meaning a lower amount of overhead doing everything else. Rather than thinking of it as losing 70% of the time doing the read, I look at that as losing 30% of your time doing non-reading activities. Not a bad stat, but also not without room for improvement either.Before delving too far though, make sure you’re not in the realm of micro-optimizations. I can tell you now that it doesn’t look like you’re doing it all wrong, so unless you’ve benchmarked your code and determined that it’s running slower than what is acceptable for your requirements, just don’t worry about the performance. If your program isn’t performing fast enough to do it’s job, then you’ll need to start with how long it’s currently taking and how long it needs to take to be “fast enough”.