Discussion :

[AJemni]

Bonjour,
Mon problème est la suivante :
J’ai une application qui lit un fichier csv source, au cours de la lecture, une ligne est splitté puis on vérifie les valeurs avec d’autres valeurs... (config)
mais ce fichier peut avoir une taille qui dépasse 1,4Go , là, la performance se dégrade et le temps d'exécution de cet étape, prévue être la plus rapide, devient la plus longue .

Je demande votre aide pour avoir une solution plus fiable et performante.

[giova_fr]

HMmm je ne vois pas trop le rapport avec les winforms

Et puis vous n'avez pas fait l'effort de vous relire visiblement...

Bref...
La comparaison de string c'est long, tu peux faire du hashage GetHash()
travailler avec plusieurs buffers/thread eventuellement. C'est sujet aussi vaste que votre question

[SaumonAgile]

Bah c'est bien beau ton explication, mais le problème peut venir de plein de choses. Donne nous le code que tu utilises et on verra ce qu'on peut faire avec ça

[Arsou]

Tout dépens de ce que tu veux en faire.

Soit tu lit ta base de donnée en direct et il faut changer de format (genre de l'XML avec une recherche sur une key).

Soit tu peux te permettre de mettre ton fichier en mémoire dans une collection fortement typée, ce qui va accélérer son traitement.


Mais comme le dis SaumonAgile, sans un bout de code, on ne peut te donner que des réponse vague et générique.

[olibara]

Soit tu lit ta base de donnée en direct et il faut changer de format (genre de l'XML avec une recherche sur une key).

Ne nous egarons pas !
L'XML n'est pas la panacée uniiverselle et certainement pas dans ce cas ci !
Ajemni parle d'un fichier CSV de plus de 1,4 GB !
Donc ni une base de donnée ni un fichier XML

Soit tu peux te permettre de mettre ton fichier en mémoire dans une collection fortement typée, ce qui va accélérer son traitement.

Allons allons
On parle d'un fichier CSV > que 1,4 GB

Je supose que ce fichier est lu ligne par ligne avec un streamreader
Il est evident que la lecture du fichier va prendre un certain temps
Mais pour tout probleme de performance la premiere chose a faire c'est d'identifier les operations les plus gourmandes, il faut essayer de gagner du temps là ou on en perds le plus

Je conseille a Ajermni de verifier déja le temps de parcours en lecture du fichier sans faire aucun traitement
Cela permettra de verifier la part du temps nécessaire au traitement et celle de la lecture simple !
Je miserais 35% en lecture et 65% en traitement
Et si le traitement comprends une ecriture sur le meme disque il y a certainement moyen d'optimiser

[AJemni]

Merci pour votre réponse olibara ça m'encourage fortement…
En faite, la lecture du fichier est ligne par ligne, puis je splitte le fichier selon le séparateur ‘\t’.
On isolant la lecture du fichier et le split, ça prend 52s tant-dis que tous le traitement dure 3min !
Le traitement est une vérification des valeurs de ligne et il est comme suite :

–Charger un config à partir d’une base de données dans des structures déjà réalisées(Existant) (source du problème !).

–Lecture du fichier ligne par ligne et pour chaque ligne lu, le splitter puis vérifier les valeurs qu’il contient en les comparant avec ceux du config ; recherche puis comparaison.

–Si erreur de comparaison, on sauvegarde la valeur erroné dans une liste et on continue le traitement.

–A la fin du traitement, toutes les valeurs erronées, si existe, sont écrites dans un fichier.

Mais en vérifiant les structures utilisées, j’ai réalisé que la recherche prend un temps considérable, alors j’ai remplacé la structure utilisé par un dictionnaire(Dictionary<string, string>) dont le Key est le code de la config (base de données) et je cherche simplement avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ContainsKey(key)

car la valeur lit à partir du fichier n'est qu'un code de la config.
Le traitement s’est réduit maintenant un peut prés à 1min et un peut plus que 30s si le fichier ne contient pas des valeurs erronées et entre 2 à 3min selon le nombre des erreurs qu'il contient mais c’est toujours long…
Et si toutes les valeurs du fichier sont erroné, Benh là, c'est la catastrophe, plus de 30min, mais ce cas n'arrivera jamais car le taux d'erreur permis sur le fichier CSV est une pour chaque 100000 valeurs c'est à dire 160 erreur pour un fichier de 16 millions de ligne.
Si une structure plus rapide existe et qui stabilise le traitement à 1min et pas plus de 1min et 30s je serai vraiment ravis de la connaitre.

Merci à vous tous.

[olibara]

Salut

Ton idée de dictionnaire est bonne car il travaille en hashing et c'est tres rapide.

Par contre ce qui m'interpelle c'est que tu dis que quand tu n'a aucune erreur, le traitement et beaucoup plus rapide ?

Comment se caractérise une erreur ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ContainsKey()

Doit te rendre rendre true au false ?
Quels sont les traitements effectués si une erreur est détectée ?

Peux tu montrer la portion de code concernée ?

[Arsou]

Ne nous egarons pas !
L'XML n'est pas la panacée uniiverselle et certainement pas dans ce cas ci !
Ajemni parle d'un fichier CSV de plus de 1,4 GB !
Donc ni une base de donnée ni un fichier XML

Je vais peut-être dire une connerie mais un CSV sert à contenir des données et un XML sert à contenir des données. Je voudrai bien que tu m'expliques pourquoi le CSV est préférable à l'XML.

Allons allons
On parle d'un fichier CSV > que 1,4 GB

Oui et? Il fait 1,4GB sur le disque et complet, si il met en mémoire uniquement les keys et les Values dont il à besoin ça prendra beaucoup moins d'espace mémoire (c'est d'ailleurs ce que AJemni fait puisqu'il place ces données dans un dictionnaire).
Je n'ai parler nul part de placer tout le fichier en mémoire (Edit: après relecture, je me suis effectivement mal exprimé, mea culpa).

AJemni: j'ai peut-être une idée stupide (enfin à peine plus que d'habitude ^^)
Utiliser un fichier index qui ne contiens que les références, ce qui permet de faire une recherche sur un plus petit fichier.
Maintenant il faut voir si ton programme serai plus rapide avec en fonction du traitement des données (si le traitement est systématique, je ne pense pas que ça soit utile de faire ce genre de fichier).

[olibara]

Je vais peut-être dire une connerie mais un CSV sert à contenir des données et un XML sert à contenir des données. Je voudrai bien que tu m'expliques pourquoi le CSV est préférable à l'XML

Oui mail il est parfois nécessaire de distinguer contenant et contenu !

Une mobilette peut servir a transporter des personnes
Un autobus aussi !
Mais je n'ai pas de place dans mon garage pour un autobus ....

Sais tu comment est constitué un fichier XML ?
Sais tu comment est constitué un fichier CSV ?

Peux tu imaginer le volume que prendrait un fichier CSV de 1,4 GB converti en XML ?

Mais ormis cette parenthese il est toujours preferable d'analyser les difficultés et contrainte d'un contexte existant avant de proposer de tout changer

[Arsou]

Effectivement, je n'avais pas vu le problème sous cet angle .

Merci d'avoir éclairer ma lanterne .