Tengo una aplicación .NET 2.0 WinForms que se conecta a un servidor WAS backend. Estoy usando GZipStream para decodificar los datos que regresan de una llamada HttpWebRequest hecha al servidor. Los datos devueltos son CSV comprimidos, que Apache está comprimiendo. La pila de servidores completa es Hibernate -> EJB -> Spring -> Apache.

Para respuestas pequeñas, el rendimiento está bien (<50 ms). Cuando recibo una respuesta> 150KB, se tarda más de 60 segundos en descomprimir. La mayor parte del tiempo parece gastarse en el constructor GZipStream.

Este es el código que muestra dónde obtengo la secuencia de respuesta de la llamada HttpWebResponse:

using (Stream stream = this.Response.GetResponseStream())
{
 if (this.CompressData && this.Response.ContentEncoding == "gzip")
 {
        // Decompress the response
  byte[] b = Decompress(stream);
  this.ResponseBody = encoding.GetString(b);
    }
 else
 {
  // Just read the stream as a string
  using (StreamReader sr = new StreamReader(stream))
  {
   this.ResponseBody = sr.ReadToEnd();
  }
 }
}

Editar 1

Basado en el comentario de Lucero, modifiqué el método de Descompresión a lo siguiente, pero no veo ningún beneficio de rendimiento al cargar el ResponseStream en un MemoryStream antes de crear una instancia del GZipStream.

private static byte[] Decompress(Stream stream)
{
 using (MemoryStream ms = new MemoryStream())
 {
  byte[] buffer = new byte[4096];
  int read = 0;

  while ((read = stream.Read(buffer, 0, buffer.Length)) > 0)
  {
   ms.Write(buffer, 0, read);
  }

  ms.Seek(0, SeekOrigin.Begin);

  using (GZipStream gzipStream = new GZipStream(ms, CompressionMode.Decompress, false))
  {
   read = 0;
   buffer = new byte[4096];

   using (MemoryStream output = new MemoryStream())
   {
    while ((read = gzipStream.Read(buffer, 0, buffer.Length)) > 0)
    {
     output.Write(buffer, 0, read);
    }

    return output.ToArray();
   }
  }
 }
}

Basado en el código anterior, ¿alguien puede ver algún problema? Esto me parece bastante básico, pero me está volviendo loco.

Editar 2

Perfilé la aplicación usando ANTS Profiler, y durante los años 60 de descompresión, la CPU está cerca de cero y el uso de la memoria no cambia.

Editar 3

La desaceleración real parece ser durante la lectura de

this.Response.GetResponseStream

La totalidad de los 60 se gastó cargando el flujo de respuesta en el MemoryStream. Una vez que está allí, la llamada a GZipStream es rápida.
Editar 4

Descubrí que el uso de HttpWebRequest.AutomaticDecompression presenta el mismo problema de rendimiento, por lo que estoy cerrando esta pregunta.