¿Por qué este circuito Parallel.ForEach no mejora el rendimiento?

Question

tengo el siguiente código:

  if (!this.writeDataStore.Exists(mat)) 
      { 
       BlockingCollection<ImageFile> imageFiles = new BlockingCollection<ImageFile>(); 
       Parallel.ForEach(fileGrouping, fi => DecompressAndReadGzFile(fi, imageFiles)); 


       this.PushIntoDb(mat, imageFiles.ToList()); 
      } 

DecompressAndReadGzFile es un método estático en la misma clase que este método está contenida en De acuerdo con el nombre del método que estoy descomprimir y leer archivos gz, muchos de ellos, es decir, hacia arriba. hasta 1000, por lo que la sobrecarga de la paralelización vale la pena por los beneficios. Sin embargo, no veo los beneficios. Cuando uso el analizador de rendimiento ANTS veo que se ejecutan exactamente en el mismo momento que si no se produce una paralelización. También compruebo los núcleos de la CPU con el explorador de procesos y parece que posiblemente se está trabajando en dos núcleos, pero parece que uno de ellos está haciendo la mayor parte del trabajo. ¿Qué no estoy entendiendo en cuanto a obtener Parallel.ForEach para descomprimir y leer archivos en paralelo?

PREGUNTA ACTUALIZADA: ¿Cuál es la forma más rápida de leer información de una lista de archivos?

El problema (simplificado):

1. Hay una gran lista de archivos .gz (1200).
2. Cada archivo tiene una línea que contiene "DATA:", la ubicación y el número de línea no son estáticos y pueden variar de un archivo a otro.
3. Tenemos que recuperar el primer número después de "DATA:" (sólo por razones de simplicidad) y almacenarlo en un objeto en la memoria (por ejemplo, una lista)

En la pregunta inicial, que estaba usando el Paralelo .ForEach loop pero no parecía estar vinculado a la CPU en más de 1 núcleo.

Answer 1

¿Es posible que los hilos pasen la mayor parte de su tiempo esperando IO? Al leer varios archivos a la vez, es posible que el disco se agite más de lo que lo haría con una sola operación. Es posible que pueda mejorar el rendimiento utilizando una sola lectura de hilo secuencialmente, pero repartir la descompresión vinculada a la CPU para separar hilos ... pero en realidad puede descubrir que solo necesita un hilo que realice la descompresión de todos modos, si el disco es más lento que el proceso de descompresión en sí.

Una forma de probar esto sería copiar primero los archivos que requieren descompresión en un disco RAM y aún así usar su código actual. Sospecho que entonces descubrirás que estás vinculado a la CPU, y todos los procesadores están ocupados casi todo el tiempo.

(también se debe considerar lo que está haciendo con los archivos descomprimidos. ¿Estás escribiendo los de vuelta al disco? Si es así, una vez más existe la posibilidad de que básicamente está a la espera de un disco paliza.)

Answer 2

¿Existe alguna posibilidad de que su método estático comparta cualquier recurso global entre sus llamadas? Porque en ese caso, este método estático se llamará de forma secuencial y sin beneficio paralelo. ¿Puedes poner tu código de clase de archivo?