Discussion :

[March']

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 !

[Geronimo]

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...

[Rich@rd]

tu a encore l'asm (assembleur) plus rapide que le c++

[kaiser2003]

ouais bah bon courage

[Geronimo]

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

[March']

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 !

[Eikichi]

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 )

[hachesse]

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

[Eikichi]

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 !)

[Geronimo]

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.

[March']

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=

[Merlin]

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.

[D[r]eadLock]

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)

[March']

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

[Traroth]

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.

[March']

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)

[Traroth]

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...

[March']

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.

[March']

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 ?!

[March']

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.