Discussion :

[godskitchen]

Bonjour,

Je voudrais vous solliciter afin de connaître une stratégie efficace pour écrire un fichier de très grande taille.

Je dispose d'un fichier de 250 Go que je désire "cropper" et ramener à une taille inférieure de ~50-70 Go en ignorant certaines données.

1) Est-il préférable de lire de grosses portions de données d'un coup et de les charger sur la RAM ?
2) Est-il préférable d'écrire de grosse quantités de données d'un coup sur le disque (par exemple par tranche de 1 Go) ou par plus petites tranches et du coup en streamant les données au fur et à mesure qu'elles sont traitées ?

Je précise que je compte multithreader mon programme étant donné qu'il est possible de traiter certaines parties des données de manière totalement indépendantes, ainsi, chaque thread de mon programme traitera ces données indépendantes et les écrira sur la mémoire RAM au fil de l'eau.

[camboui]

Travailler par zone tampon est toujours bon. Mais j'ai remarqué que travailler avec des tampons de quelques MB n'apporte pas grand chose de plus que quelques KB. Des tranches en GB n'apporteront rien AMA, le goulot d'étranglement reste le DD.

A propos des fichiers de sortie, d'habitude je les créé puis les laisse grossir au fur et à mesure des écritures. Un jour j'ai fait l'essai de créer un fichier de sortie en signalant à l'OS qu'il aura une taille déterminée et supérieure à celle estimée, puis je le tronque lors de sa fermeture à la taille réelle. Ça n'a rien changé aux performances (je pensais naïvement que l'OS perdrait moins de temps à réajuster les allocations des clusters sur le DD au fur et à mesure des écritures).

Pour le fichier d'entrée, s'il n'est lu qu'une fois, je pense qu'il n'y a pas grand chose à améliorer. S'il y a plusieures passes non séquetielles (random), un cache peut être utile. J'ai un projet avec plusieures centaines de fichiers en entrée en accès random et l'usage d'un cache m'a permis de réduire par 3 le temps d'exécution de certains prgs (dans le meilleur des cas). J'ai tout de même été surpris par ce gain, le cache de Windows Server faisant en général un assez bon boulot.

[imperio]

1) Est-il préférable de lire de grosses portions de données d'un coup et de les charger sur la RAM ?

J'aurais tendance à penser que oui mais étant donné la taille de ton fichier, je pense qu'il te faudra un compromis. Dans tous les cas, un traitement de cette taille te prendre forcément pas mal de temps.

2) Est-il préférable d'écrire de grosse quantités de données d'un coup sur le disque (par exemple par tranche de 1 Go) ou par plus petites tranches et du coup en streamant les données au fur et à mesure qu'elles sont traitées ?

Là par contre je pense être sûr de mon coup en disant d'appeler le moins de fois possible les méthodes d'écriture. Cependant à partir d'une certaine taille d'écriture, ça ne devrait plus changer grand chose. Faudra que tu te fasses des tests pour déterminer quelle méthode ira le plus vite.

Je précise que je compte multithreader mon programme étant donné qu'il est possible de traiter certaines parties des données de manière totalement indépendantes, ainsi, chaque thread de mon programme traitera ces données indépendantes et les écrira sur la mémoire RAM au fil de l'eau.

Une fois les données dans la RAM c'est une bonne idée, du moment que tu ne lis / écris pas dans le fichier depuis un thread.

[r0d]

Encore une fois, il n'y a pas de solution magique dans ce type de problème, chaque cas concret a une solution spécifique.
Ce qu'il faut faire, c'est commencer par implémenter une solution relativement générique, modulaire. Ensuite il faut profiler, déterminer les goulots d'étranglements, et optimiser en fonction.
Car par exemple, si tu as des traitements lourds sur le filtrage des données, alors le goulot ne sera peut-être pas sur les I/O. Peut être également qu'un buffer de taille fixe n'est pas une solution qui convient au traitement, de même qu'il y aura des contraintes sur le buffer qui n'apparaitront que lors d'une première implémentation.

Concernant le passage au MT, je conseille de faire ça à la fin, ou presque. Une fois que tu as un algo qui tourne convenablement, tu verras alors quels sont les endroits que tu peux multithreader. Et alors, et seulement alors, il est important d'isoler les parties de code multithreadées du reste du code (pour de sérieuses questions de maintenance).

My 2 cts.