IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Stratégie d'écriture gros volume de données


Sujet :

C++

  1. #1
    Membre averti
    Homme Profil pro
    Ingénieur à ses heures perdues
    Inscrit en
    Août 2011
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur à ses heures perdues

    Informations forums :
    Inscription : Août 2011
    Messages : 36
    Par défaut Stratégie d'écriture gros volume de données
    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.

  2. #2
    Membre éclairé
    Inscrit en
    Avril 2005
    Messages
    1 110
    Détails du profil
    Informations forums :
    Inscription : Avril 2005
    Messages : 1 110
    Par défaut
    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.

  3. #3
    Membre Expert
    Avatar de imperio
    Homme Profil pro
    Étudiant
    Inscrit en
    Mai 2010
    Messages
    869
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2010
    Messages : 869
    Par défaut
    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.

  4. #4
    r0d
    r0d est déconnecté
    Membre expérimenté

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    4 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2004
    Messages : 4 288
    Billets dans le blog
    2
    Par défaut
    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.

Discussions similaires

  1. Réponses: 2
    Dernier message: 03/12/2007, 12h48
  2. Réponses: 3
    Dernier message: 11/05/2007, 13h47
  3. [Recherche texte sur gros volume de données]
    Par tesla dans le forum Algorithmes et structures de données
    Réponses: 8
    Dernier message: 21/02/2007, 13h43
  4. Structure de données pour gros volume de données
    Par Invité dans le forum Langage
    Réponses: 9
    Dernier message: 01/02/2007, 11h58
  5. Gérer le gros volume de données
    Par berceker united dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 21/07/2006, 19h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo