2010-06-06 4 views
0

J'ai un fichier compressé dans le disque, qui est partitionné en blocs. Je lis un bloc de disque décompresser en mémoire et lire les données.Producteur/Consommateur - Disque d'E/S

Il est possible de créer un producteur/consommateur, un thread qui récupère des blocs compactés à partir du disque et mettre dans une file d'attente et un autre thread qui décompresser et lire les données?

La performance sera-t-elle meilleure?

Merci!

Répondre

0

Oui, il est possible de le configurer de cette façon. Que vous voyiez une amélioration des performances dépend énormément de la machine, de la nature exacte de ce que vous faites avec les données décompressées, etc. Si cela ne vous pose pas trop de problèmes et que votre jeu de données est important, je vous conseille de le faire. mesurer pour voir si c'est plus rapide. Si rien d'autre, il est similaire au travail que vous auriez à faire pour tirer parti d'une sorte de cadre de réduction de la carte.

+0

La carte est réduite pour les clusters d'ordinateurs. Dans mon cas, je n'ai qu'une seule machine. Comment puis-je l'utiliser? Merci –

+0

Bien que Map/Reduce soit populaire car il permet une mise à l'échelle horizontale facile en utilisant un cluster, il est parfaitement possible de l'utiliser dans des configurations à nœud unique. Consultez cet [article sur Hadoop à nœud unique] (http://hadoop.apache.org/common/docs/current/quickstart.html). –

1

Je soupçonne que le thread qui décompresse les données passe le plus clair de son temps à attendre le thread qui lit les blocs compactés à partir du disque.

Je serais surpris si la décompression liée à l'UC prenait plus de temps que la lecture des blocs à partir de l'E/S.

+0

Tout dépend des disques et de la compression que vous utilisez, par ex. la décompression des fichiers gzippés est de loin liée à nos serveurs. – nos

+0

C'est le point. Si j'utilise une compression lourde, le thread de décompression n'attendra probablement pas le thread d'E/S, et j'aurai alors un gain de performance. –