Discussion :

[gene69]

Bonjour

j'ai un écrit un programme qui fait un traitement sur un fichier plat (environ 400000 lignes 100Mo ) et j'arrive a avoir une vitesse de traitement de 10000 à 20000 lignes selon l'ordinateur qui exécute le programme.

Comme c'est un programme qui pourrait fonctionner sur le modèle producteur-consommateur, je me demande si je peux espérer une amélioration des performances si je rend l'algorithme parallèle (un thread pour la lecture des données, d'autres pour le traitement par lot des données lues) sur une machine multiprocesseur et si je risque de payer "cher" la couche thread pour un ordinateur monoprocesseur.

merci

[elmor]

Oui tu peux surement obtenir un gain de performance si tu utilises des threads.

Mais même sur un monoprocesseur car lorsqu'un ton thread de lecture sera bloquée sur l'io pour lire dans le fichier, le thread de traitement pourra faire du boulot en fait dans tous les cas tu es gagnant.


Sinon si tu n'es pas obligé de lire ton fichier de façon séquentielle tu peux encore améliorer les performances en découpant ton fichier en plus petit morceaux lut en parallèle par des threads.

[gene69]

je viens de faire quelques tests, il se trouve que la partie lecture du fichier prend 15 secondes et les traitements 6 secondes sur ma machines. D'ailleurs je suis déçu parce que la lecture du fichier est assez lente.. est ce qu'il y a des primitives plus efficaces que bufferedReader(File)?

c'est en effet une idée intéressante de "découper le fichier" mais je ne vois pas trop comment faire pour déplacer "la tete de lecture" du thread à une position arbitraire dans le fichier... parce que ce qui serait intéressant serait d'attaquer le ficher par tiers ou quart de façon indépendante...

En plus j'ai peur que les threads se bloquent entre eux pour la lecture du fichier...

Sinon pour le compromis temps mémoire, je souhaite bien sur améliorer mes perf sans augmenter la consommation mémoire parce que mes premières versions saturaient toute la mémoire de la machine virtuelle java (et y avait pas de bug): résultat la mémoire est une ressource critique (je saturais même avec des options -Xmx800m parce que j'avais beaucoup d'objets créés...)

[adiGuba]

Salut,

je viens de faire quelques tests, il se trouve que la partie lecture du fichier prend 15 secondes et les traitements 6 secondes sur ma machines. D'ailleurs je suis déçu parce que la lecture du fichier est assez lente.. est ce qu'il y a des primitives plus efficaces que bufferedReader(File)?

Ca dépend de ce que tu veux faire et de la manière dont tu traites les données... Bref il nous faut plus d'infos...

En plus j'ai peur que les threads se bloquent entre eux pour la lecture du fichier...

Perso je ne pencherais pas non plus vers cette optique...
Un seul thread de lecture, et plusieurs threads pour traiter les données.

A la rigueur tu pourrais utiliser Runtime.getRuntime().availableProcessors() pour obtenir le nombre de processeur et créer autant de threads...

Sinon pour le compromis temps mémoire, je souhaite bien sur améliorer mes perf sans augmenter la consommation mémoire parce que mes premières versions saturaient toute la mémoire de la machine virtuelle java (et y avait pas de bug): résultat la mémoire est une ressource critique (je saturais même avec des options -Xmx800m parce que j'avais beaucoup d'objets créés...)

Whoua tu gères une grosse quantité de donnée on dirait !
On pourrais avoir une idée de ce que cela représente ? (format et taille des données)

a++

[gene69]

(environ 400000 lignes 100Mo )

le traitement que je fait est assez simple: je lis des données dans un fichier texte (csv)

je les parse et les analyse, les corrige et je les positionne dans un tableau à deux dimensions en fonction de plusieurs critères (par exemple si je détecte une adresse ip alors je la place dans la colonne de la plage réseau appropriée, ensuite je vais altérer un tas de propriété de la case etc.

et à la fin je crée un rapport sous forme d'un beau document xhtml avec mon tableau, avec du package fait maison. Le problème c'est que j'ai fait simple et que je crée un arbre xhtml puis je l'écrit dans un Writer. Le tableau fait 850*850 balises TD et les balises TD contiennent d'autres noeud... et finalement j'ai mis un objet par noeud et donc même si chaque objet n'est pas lourd à la fin j'ai plus de deux millions de hashtable dans la jvm.
Le rendu en lui même est rapide... si j'ai assez de mémoire pour générer l'arbre.

bon pour ce qui est de l'utilisation des threads, j'étais bien séduit par l'idée d'avoir plusieurs fileReader sur des sections différente du fichier et à la fin merger toutes les informations collectée par chaque thread. Mais pour celà il me faudrait la certitude que les fileReader ne se bloquent pas entre-eux et j'ai pas encore de certitude sur le sujet.

Pour faire un consommateur qui ne fait que lire le fichier et d'autre qui ne font que le traitement, pourquoi pas. dans ce cas il faut que je mette un truc pour que les thread se donne des données entre deux... je penche pour un pipedWriter/pipedReader c'est juste?
Mais dans ce cas, qu'est ce que je vais gagner comme gain de performance puisqu'il me faut 3 fois plus de temps pour lire une donnée que pour faire le traitement nécessaire ?

[gene69]

je viens de vérifier un truc, en fait c'est pas la lecture du fichier qui est longue c'est toute la phase de parse des données (je l'avais laissé dans la partie lecture tout à l'heure) et c'est elle qui me ralenti la lecture des données par 10.

sans vous j'aurrai pas cherché de ce côté.

[elmor]

Cool donc maintenant il ne reste plus qu'a régler le problème de la mémoire

Et la, je pense qu'un utilisant une boundedQueue du genre ArrayBlockingQueue
et un ThreadPoolExecutor ton problème sera réglé.

Il faut juste que tu configures ton ThreadPoolExecutor pour bloquer ton thread qui lit les données lorsque la queue ou tu envoies les donnees à traiter est pleine.

Est-ce que tu utilises un threadPoolExecutor et une queue ?