Task Lists: Improve performance

[justcoding121]

Now that we have a relatively stable project its time to tune performance.

• Noted abrupt slowdown/termination of HTTPS requests on long run. (need to find out why). Improper handling of Proxy-Connection header may be the issue or is it because cache locks causing dead locks?
  update:The issue was with TcpConnectionCache which mixed up connections; removed it. Also enabled LingerState with 0 timeout to free ports immediately after connection close to avoid port exhaustion. (due to default TCP CLOSE_WAIT timeout for 4 minutes)
• Need to replace List of HttpHeader with a Dictionary for faster lookup. This comes at the cost of creating an additional header Dictionary (headerkey, header List) for non-unique headers. (like cookies)
• Replacing often used String.Format with a low level concatenation can be error prone if not careful, but it may provide negligible performance benefits. (So do it if we get a chance).
• Reduce any castings that would unnecessarily involve moving objects between heap & stack
• Reduce any data structure conversions that could be costly.

[honfika]

Thank you for merging my PR.

The next major problem is in CustomBinaryReader.ReadLineAsync:
while (await stream.ReadAsync(buffer, bufferDataLength, 1) > 0)

95+% of the first 4 allocations (more than 1 million, which is 81% of the total allocations) are called from this line.

Actually I spent more time on trying to fix this problem than on the PR, but I had to revert those changes because they were not so good solutions. I tried to add a buffer which keeps the data between the ReadLine calls, but the underlying stream is used outside of the CustomBinaryReader class, too, In this case the remaining data in the inner buffer is ignored/lost, which is wrong (e.g when the stream is converted to SslStream).
Another soultion would be to check the type of the stream. Because NetworkStream has a DataAvailable property, and regarding to the documentation when it is true the non async Read returns immediately.
But it does not work for SslStreams, and I think it is a "hack" to check the stream type.
Maybe the best solution would be to wrap the streams to a CustomBufferedStream, which has an inner buffer and it returns the data immediately if it is available in the buffer.

Another suggestion:
In this case:

          using (var output = new MemoryStream())
             {
                 int read;
                 while ((read = await decompressor.ReadAsync(buffer, 0, buffer.Length)) > 0)
                 {
                     await output.WriteAsync(buffer, 0, read);
                 }

                 return output.ToArray();
             }

I think the 2nd await (on MemoryStream.WriteAsync) is unnecessary. It is not an IO intensive/bound operation, so it can be synchronous. But it is not a big issue.

[justcoding121]

I was previously stuck on CustomBinaryReader.ReadLineAsync , and reached the same conclusion. So one day may be we can come up with CustomBufferedStream.

For await output.WriteAsync(buffer, 0, read) I think the idea is that if the output network buffer is full, then we have to wait asynchrounously until it is free. (until client starts reading the data)

[honfika]

Yes, but it is a MemoryStream.
If it would be a network stream or filestream, then of course, it is needed.

[justcoding121]

Right. We can remove it then. Wow that customBufferedStream was really quick. I will look at it when I get home.