Version imprimable
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 8O, 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 :roll:.
Je demande votre aide pour avoir une solution plus fiable et performante. :aie:
HMmm je ne vois pas trop le rapport avec les winforms 8O
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 :)
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 ;)
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.
Ne nous egarons pas !Citation:
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).
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
Allons allons :roll:Citation:
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.
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
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 aveccar la valeur lit à partir du fichier n'est qu'un code de la config.Code:ContainsKey(key)
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. :bug:
Merci à vous tous.
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 ?
Doit te rendre rendre true au false ?Code:ContainsKey()
Quels sont les traitements effectués si une erreur est détectée ?
Peux tu montrer la portion de code concernée ?
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.Citation:
Envoyé par olibara
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).Citation:
Envoyé par olibara
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).
Oui mail il est parfois nécessaire de distinguer contenant et contenu !Citation:
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
Une mobilette peut servir a transporter des personnes
Un autobus aussi !
Mais je n'ai pas de place dans mon garage pour un autobus .... :mrgreen:
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
Effectivement, je n'avais pas vu le problème sous cet angle :oops:.
Merci d'avoir éclairer ma lanterne :).
Bonjour,
En faite j’ai 5 valeurs a vérifiées pour chaque ligne, et chaque valeur parmi eux est exactement sur 3 caractères, et lors du traitement, si une erreur de comparaison est détecté, j’ajoute l’erreur à une liste(Le class Item est un couple (NumLigne, CodeErronee)) et au fur et au mesure que le nombre d’erreur augmente, la liste augmente de taille, puis écriture dans un fichier Texte, et accès à la base de données pour enregistrer l’erreur (modifier l’état du traitement de vérification en erroné) et enfin envoyé le fichier texte ainsi générer comme pièce jointe dans un mail en appelant un Web Service.Code:List<Item>
Le problème et que le nombre d’erreur dans le fichier ne respecte pas la tolérance d’erreur que j’ai mentionné (une pour chaque 100000 ligne) et le nombre des valeurs erronées peut être variable et par exemple si une erreur est détecté pour chaque ligne pour un fichier de 1,4Go (un peut près de 16 millions de lignes), j’aurai une liste de taille qui dépasse largement 45 Mo.
Alors, j’ai pensé à la chose suivante :
au lieu de remplir chaque fois la liste, et à la fin du traitement j’écris dans un fichier texte, j’ouvre directement un StreamReader et j’écris directement dans le fichier mais mon souci est :
Est-ce que le flux ouvert tout au long du traitement n’influ pas sur la performance ?
Merci
Salut
Franchement tu pourrais essayer d'etre plus clair et aussi montrer parfois des bouts de code pour mieux illustrer ce que tu fais.
C'est pas facile de te comprendre dans le texte :roll::(
Je suppose que tu veux dire un StreamWriter !Citation:
au lieu de remplir chaque fois la liste, et à la fin du traitement j’écris dans un fichier texte, j’ouvre directement un StreamReader et j’écris directement dans le fichier mais mon souci est :
Oups! :oops:
pardon, un StreamWriter...:aie:
et concernant le bout de code c'est super long à lire...
Et franchement, je vous remercie olibara pour ton aide et à tous les autres aussi.
Merci
:koi:Citation:
et concernant le bout de code c'est super long à lire...
Si le code en cause est si long par rapport a ce que tu explique ca ne m'étonnerait donc pas qu'un petit debroussaillage soit utile ;)
En tout cas quelques piste
1- Inserer des millions d'element dans une liste, ca prends forcement du temps !
2- Dans ce cas il vaux mieux travailler comme tu le fais avec un tableau buffer que tu vide dans ton stream tous les n element (pour eviter de d'alterner trop souvent lecture et ecriture : ca bouffe aussi de la performance)
Non!Citation:
Est-ce que le flux ouvert tout au long du traitement n’influ pas sur la performance ?
Seulement quand tu ecrit ....