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

Langages de programmation Discussion :

Un langage pour lire, traiter et écrire de gros fichiers


Sujet :

Langages de programmation

  1. #1
    Membre à l'essai
    Inscrit en
    juillet 2002
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : juillet 2002
    Messages : 28
    Points : 17
    Points
    17
    Par défaut Un langage pour lire, traiter et écrire de gros fichiers
    Bonjour à tous !

    Dans le programme que je développe actuellement, j'ai un module qui doit intervenir sur des gros fichier.

    C'est, en fait, un convertisseur de type "les CR en CRLF" avec pleins d'autres options...

    Le problème vient du fait qu'il doit traité de gros fichier, genre 200Mo, et même plus si affinité....

    Pour le moment, je travail avec un fichier de 48 Mo.

    Avec Visual C++ 6, j'arrive à traiter ce fichier, selon les méthodes utilisées, en 50 secondes pour le mieux, et 3 minutes pour le pire.
    Avec Perl, entre 1 minute et QQ heures...

    N'ayant pas d'autre langage à disposition (et n'ayant pas d'idée surtout !)
    je sollicite votre expérience pour m'orienté vers un langage performant au niveau I/O GROS fichier.

    PS : pour info, j'ai un utilitaire qui peut faire la même convertion en 30s pour le même fichier. Malheureusement, je n'ai aucune info sur l'origine de cet exe...

    Merci d'avance pour vos réponses !

  2. #2
    Membre chevronné
    Avatar de Geronimo
    Profil pro
    Inscrit en
    avril 2002
    Messages
    156
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 156
    Points : 1 939
    Points
    1 939
    Par défaut
    Tu auras du mal à trouver un langage beaucoup plus rapide que le C++;
    Perl, c'est normal qu'il soit très lent, c'est un langage de très haut niveau.

    Il faut plutôt que tu cherches à optimiser tes algorithmes...
    Une question concernant C++Builder ? Voici la réponse
    Consultez aussi les tutoriels de qualité de la section C/C++

  3. #3
    Candidat au Club
    Profil pro
    Inscrit en
    juillet 2002
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2002
    Messages : 3
    Points : 4
    Points
    4
    Par défaut
    tu a encore l'asm (assembleur) plus rapide que le c++
    @+
    Rich@rd

  4. #4
    Membre du Club
    Profil pro
    Inscrit en
    février 2003
    Messages
    59
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2003
    Messages : 59
    Points : 41
    Points
    41
    Par défaut
    ouais bah bon courage

  5. #5
    Membre chevronné
    Avatar de Geronimo
    Profil pro
    Inscrit en
    avril 2002
    Messages
    156
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 156
    Points : 1 939
    Points
    1 939
    Par défaut
    L'assembleur est plus rapide que le C++, à condition de savoir bien programmer en assembleur... sinon, on risque de faire plus lent. Et vu le temps passé à apprendre l'assembleur, tu n'y gagneras pas vraiment de temps. C'est la raison pour laquelle je n'ai pas cité l'assembleur.

    Plus rapide que le C++, tu pourrais avoir le C. C'est-à-dire que l'utilisation de classes, etc. en C++ est légérement pénalisante sur le plan performances, mais je doute que cela ait beaucoup d'incidence pour ton problème.

    Je pense vraiment que dans ce cas, c'est un question d'optimisation ; de l'algorithme lui-même, tout d'abord, et ensuite penser à optimiser le code (pour les boucles, par exemple, pas de recalcul des valeurs maximum)

    Cordialement
    Geronimo
    Une question concernant C++Builder ? Voici la réponse
    Consultez aussi les tutoriels de qualité de la section C/C++

  6. #6
    Membre à l'essai
    Inscrit en
    juillet 2002
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : juillet 2002
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    Bon, pour l'assembleur, ce sera pour plus tard ...

    Et que pensez-vous de Delphi ?

    Sinon, au niveau Algo, j'avais pensé faire un truc un peu complexe avec un thread qui charge mon fichier en petit morceaux, un autre thread pour la convertion des morceaux et encore un autre pour écrire

    Mais là, je sais pas trop si c'est bonne idée, et je sais pas trop comme l'implementer.

    Et à part ce schéma délirant, et le schéma classique "Je lis, je convertis, j'écris", avez-vous d'autre idée pour executer un tel traitement ?

    PS : C'est quoi le 'Déplacé' devant le sujet ? C'est la question que je pose qui est 'Déplacée' ou ça veux totalement autre chose ?

    Merci encore pour toutes vos remarques !

  7. #7
    Membre du Club
    Homme Profil pro
    Directeur agence SSII
    Inscrit en
    août 2002
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37

    Informations professionnelles :
    Activité : Directeur agence SSII
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : août 2002
    Messages : 25
    Points : 43
    Points
    43
    Par défaut
    Non, le sujet a été déplacé dans un autre forum... "Langages en Général"

    Qui dit Delphi dit Pascal Objet, rapide... mais moins que C ou C++ d'après mon expérience.

    (message édité car il portait un peu à confusion )
    Java & Arduino

  8. #8
    Membre confirmé
    Avatar de hachesse
    Inscrit en
    mars 2002
    Messages
    189
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 189
    Points : 626
    Points
    626
    Par défaut
    Delphi me parrait un tres bon choix. Et contrairement ca que certain semble croire, c'est tres rapide comme langage.

    Par contre, plus important que le langage que tu utilise, c'est la methode que tu vas utiliser pour lire ton gros fichier.

    En delphi, il y a le Mappage du fichier (FileMapping) ou le traitement par lot (chunk by chunk) ar exemple

  9. #9
    Membre du Club
    Homme Profil pro
    Directeur agence SSII
    Inscrit en
    août 2002
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37

    Informations professionnelles :
    Activité : Directeur agence SSII
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : août 2002
    Messages : 25
    Points : 43
    Points
    43
    Par défaut
    Citation Envoyé par hachesse
    Delphi me parrait un tres bon choix. Et contrairement ca que certain semble croire, c'est tres rapide comme langage.
    J'ai pas dit que c'était lent non plus !

    Mais là n'est pas la question (enfin un peu quand même !)
    Java & Arduino

  10. #10
    Membre chevronné
    Avatar de Geronimo
    Profil pro
    Inscrit en
    avril 2002
    Messages
    156
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 156
    Points : 1 939
    Points
    1 939
    Par défaut
    Quel que soit le langage que tu choisis, je pense qu'il faut surtout que tu repenses ton algorithme ; pourrais-tu en donner le principe ici, que l'on puisse donner notre avis ?

    La différence de vitesse en Pascal Objet et C++ n'est pas du tout flagrante : ce sont deux langages compilés. Le C/C++ étant plus proche du système (pointeurs, etc.), il sera quelque peu plus rapide.
    Une question concernant C++Builder ? Voici la réponse
    Consultez aussi les tutoriels de qualité de la section C/C++

  11. #11
    Membre à l'essai
    Inscrit en
    juillet 2002
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : juillet 2002
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    L'algo est trés simple, je parcours tout le fichier caractaire par caractaire.
    Voilà l'adresse, d'un de mes post sur le sujet :

    http://www.developpez.net/forums/vie...712&highlight=

  12. #12
    Membre émérite
    Avatar de Merlin
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mars 2002
    Messages
    524
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : mars 2002
    Messages : 524
    Points : 2 838
    Points
    2 838
    Par défaut
    tu balaye char par char ? Par quel méthode ? en lisant réellement char par char le fichier ? Si c'est çà normal que çà soit long.

    La première optimisation dans ce genre de traitement c'est la gestion des buffers d'entrée et sortie.
    Il faut lire le fichier origine par bloc de 64k ou plus (faire des tests, l'efficacité varie selon les disques, les os..) et écrire pareil, par bloc.
    Une autre optimisation consiste à préallouer l'espace du fichier de sortie, et donc dans la boucle ne pas créer ce dernier mais simplement effacer les blocs alloués (les allouer à vide, sans écrire dedans sinon on perd du temps). Il doit y avoir des fonctions de l'os pour préallouer un fichier d'une certaine taille mais je n'ai pas çà en mémoire.

    Pour le buffer d'entrée il y a une taille maxi au dessus de laquelle on ne gagne plus de temps. comme je le disais il faut tester.
    Pour le buffer de sortie par contre on peut généralement en mettre un très gros : moins il y a d'écritures disque, moins c'est lent. Là aussi il existe un palier, seul les tests te permettront d'optimiser.
    D'ailleurs les tailles de buffers (e/s) doivent pouvoir être modifiés par paramètrage du soft (au cas où).

    Pour faire çà Delphi est parfait, et même un bon vieux Turbo Pascal :-)
    Les fonctions BlockRead et BlockWrite sont ultra rapides et adressent des fonctions de l'OS sans intermédiaire.

  13. #13
    Membre éclairé
    Avatar de D[r]eadLock
    Profil pro
    Inscrit en
    mai 2002
    Messages
    504
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : mai 2002
    Messages : 504
    Points : 747
    Points
    747
    Par défaut
    J'arrive peut-etre un peut tard, mais je suis etonne que le perl soit si lent sur ce genre de truc. C'est peut-etre que tes expressions reguliere etaient trop gourmandes ! J'ai constate des differences phenomenales en changeant juste un peu des expressions reguliere (qui faisaient au final la meme chose).

    Par curiosite, il est long ton ex-code perl ? (stp, envoi-le moi par MP)

  14. #14
    Membre à l'essai
    Inscrit en
    juillet 2002
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : juillet 2002
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    Pour le test en Perl, j'ai pas fait compliqué :

    Il n'y a pas plusieurs filtre et je lis un fichier que j'écris en dur dans le script :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    if ( ($taille = -s 'MonFichier') > 0 )
    {
    	print "taille = $taille\n";
    	open( IN, 'MonFichier') or die "ouverture impossible";
    	open( OUT, '>', 'SORTIE.out') or die "ouverture fichier sortie impossible";
    	binmode(IN);
    	binmode(OUT);
    	$/="\r\n";
    	while &#40; $bloc = <IN> &#41;
    	&#123;
    		$bloc =~ s/\r\n/\n/;
    		print OUT $bloc;
    	&#125;
    	close &#40; IN &#41;;
    	close &#40; OUT &#41;;
    &#125;
    J'edite le message pour vous préciser que je tourne sur un PII 366 avec 196 de RAM

  15. #15
    Inactif
    Profil pro
    Inscrit en
    avril 2002
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 51
    Points : 57
    Points
    57
    Par défaut
    A mon humble avis, l'algorithme est plus important que le langage, honnetement. Ce qui nous amene à la qestion cruciale : quels types de traitements veux-tu faire ? En particulier, as-tu besoin de memoriser tout ton fichier ? Sinon, je pense qu'il vaudrait mieux le traiter par petit bout. Evidemment, si ça n'est pas possible...
    Dans tout les cas, C++ est un bon choix, surtout si tu connais bien. C'est un langage un peu capricieux pour les débutants, en revanche. Dans ce cas, tu peux tenter Java. J'ai personnellement ecrit un programme qui lisait des fichiers ASCII relativement volumineux (rien de comparable avec le tien, note bien) et qui traitait un fichier de 10000 lignes (soit 1.5 Mo) en 30 secondes environ. Mais je pouvais me permettre de le traiter ligne par ligne, sans memoriser tout le fichier.

  16. #16
    Membre à l'essai
    Inscrit en
    juillet 2002
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : juillet 2002
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    Ecoute, si tu à un algo de recherche performant, je prends !

    Mais pour être précis, je pense qu'il y a un moyen d'optimiser la lecture et l'écriture du fichier. Avec mon code en C++ (le code qui à le plus d'options et qui fonctionne le plus vite), les traitement de lecture et d'écriture sont très long par rapport au traitement des chaines de ce fichier. En effet, la lecture prends environs 23 secondes, le traitement environs 7 secondes et l'écriture environs 29 secondes.

    Si tu t'amuses à calculer les débits des disques durs, je pense qu'il sont vraiment faible : lecture => 2 Mo/s, écriture => 1,6 Mo/s !

    C'est pire que dans les LAN que je fais dans mon garage !
    (ou j'ai une fausse idée sur les débits des disques durs ou j'ai oublié QQchose... PREVENEZ MOI DANS CE CAS ! Merci)

    C'est pour ça que j'ai plutôt demandé un langage ou alors une méthode pour lire et écrire de gros fichiers.

    Notez que pour lire/écrire mes fichiers en C++, j'ai utilisé CreateFile() ou open() sans grande différence ( 1 ou 2 seconde(s) sur un traitement complet: Lecture, traitement, écriture)

  17. #17
    Inactif
    Profil pro
    Inscrit en
    avril 2002
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 51
    Points : 57
    Points
    57
    Par défaut
    MA problèmatique semble assez differente de la tienne.
    Ce que je faisais (en Java) :

    -Lire une ligne (C'est à dire constituter un StringBuffer en lisant le fichier caractère par caractère jusqu'à arriver à un retour chariot)
    -Detecter de quel type de ligne il s'agit
    -Extraire, en fonction de ce type, un certain nombre d'informations de la ligne
    -Inserer ces données dans un arbre DOM et/ou dans une base de données
    -Si fin de fichier, ecrire le fichier XML correspondant à l'arbre DOM

    Pour les connaisseurs en Java (on est limite hors sujet et hors forum, là), c'estr l'utilisation du StringBuffer qui permet d'etre beaucoup plus performant. Mais si tu dis que ton problème vient surtout des E/S disque, j'avoue que je ne serais pas d'une très grande aide...

  18. #18
    Membre à l'essai
    Inscrit en
    juillet 2002
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : juillet 2002
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    En effet, je pense qu'en limitant les accés disque, on arrive à gagner QQ secondes, alors toi, tu les multiplis !

    Si tu préfère, je suis choqué par les performances de lecture/écriture, car elles me semblent très faibles. Et si elles sont faibles, je pense qu'il y a un moyen de les doper un peu.

    Je suis peut-être trop gourmant , d'autant plus que le programme que je développe tournera sur des machines un peu plus à jour que la mienne. Mais j'aimerai être sur que je ne peu pas faire autrement.

  19. #19
    Membre à l'essai
    Inscrit en
    juillet 2002
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : juillet 2002
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    Je viens de reprendre mes investigations sur le sujet, et j'ai trouvé le "FILE-MAPPING" qui s'effectue avec les fonction du genre CreateFile(), ReadFile() et WriteFile(), mais surtout CreateFileMapping() et MapViewOfFile().

    Vous connaissez ?

    Ca me semble assez efficace sur le papier, mais j'ai pas eu le temps de faire un essai.... En plus, on peut partager le fichier lu entre plusieurs process d'apres ce que j'ai compris.

    Est-ce que QQ'un pourrais me dire si ce systeme peut m'apporter un plus ?!

  20. #20
    Membre à l'essai
    Inscrit en
    juillet 2002
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : juillet 2002
    Messages : 28
    Points : 17
    Points
    17
    Par défaut
    Même si j'ai l'impression qu'il n'y a plus personne, je peux vous dire que le FILEMAPPING, c'est TRES efficace !

    J'ai pulvérisé la table des High Score !

    Voilà un appercu :

    avant : 41 Mo traités en 1 minute (en fait c'est entre 54s et 1 minute 30 celon l'algo et le style de l'implémentation)

    Maintenant : 41 Mo traités en 25 s ! ! !

    Je savais bien que je pouvais faire un truc au niveau des perfomances d'I/O. Je passe de 700 Ko/s à 1.5 Mo/s


    En plus, c'est tout simple à mettre en oeuvre, on ouvre le fichier avec CreateFile, on Map le fichier, puis, avec un pointeur on ce déplace dans le fichier sans s'occuper de la lecture du fichier (géré par Windows). Et quand on a fini, on ferme tous les HANDLE, et le tour est jouer !

    Je reste ouvert à toute remarque, et je reste prét à vous apporter une précision sur le sujet.

Discussions similaires

  1. Choix de langage pour petit programme - vérification de noms de fichiers
    Par hardcorepierre dans le forum Langages de programmation
    Réponses: 4
    Dernier message: 13/09/2011, 13h49
  2. quel logiciel pour faire du SQL sur des GROS fichiers bruts (csv)?
    Par flipo44 dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 24/06/2010, 17h59
  3. Réponses: 4
    Dernier message: 17/09/2007, 01h51
  4. Réponses: 11
    Dernier message: 24/05/2007, 18h05
  5. Quel langage choisir pour lire sur le port série ?
    Par Nico76 dans le forum Windows
    Réponses: 7
    Dernier message: 28/04/2004, 11h42

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